RFC czyli Request For Comment jest to zbiór dokumentów szczegółowo opisujących protokoły, oraz specyfikacje techniczne wymagane do ustandaryzowanej implementacji danego zagadnienia. Jest to swoista biblia dla sieciowców w której znajdują się wszystkie obecnie stosowane standardy utworzone przez EITF. Wydawało by się, że w tak poważnym zbiorze danych nie ma miejsca na żarty, w końcu zaglądają i czytają to codziennie tysiące osób na całym świecie. Nic bardziej mylnego, sieciowcy również mają poczucie humoru, specyficzne ale jednak.
RFC 1149 IP over Avian Carriers (IPoAC)
Wydany 1 kwietnia 1990 przez David Waitzman’a RFC 1149 opisuje sposób transmisji datagramu IP z wykorzystaniem gołębia pocztowego. Standard ten niestety oferuje niską przepustowość o stosunkowo wysokich opóźnieniach oraz sporym ryzyku utraty danych. Jak wysokim? W celu sprawdzenia tego Linux User Group z Bergen w Norwegii wysłali 9 pakietów ping, każdy niesiony przez 1 gołębia. Niestety współczynnik dostarczonych danych wyniósł jedynie 65%, jedynie 4 pakiety zostały skutecznie dostarczone. Czas dostarczenia pakietu wynosił pomiędzy 3000 do ponad 6000 sekund .
64 bytes from 10.0.3.1: icmp_seq=0 ttl=255 time=6165731.1 ms
Standard został zaprojektowany do komunikacji typu punkt-punkt. Typowa wartość MTU wynosi 0,256 grama oraz jest uzależniona od długości nogi gołębia. Paradoksalnie starsze „nośniki” są w stanie przenosić większe ilości danych od młodszych osobników.
RFC 2549 IP over Avian Carriers with Quality of Service
9 lat po wydaniu oryginalnego standardu IPoAC doczekaliśmy się implementacji QoS. Dzięki temu otrzymaliśmy następujące dostępny klasy serwisów: Concorde , pierwsza klasa, biznesowa, coach ( klasa ekonomiczna). Jako jedyny znany protokół sieciowy wykorzystwanie IPoAC z QoS oferuje zbieranie mil wraz z każdym pakietem. Klasa concorde oferuje przyspieszony transport danych oraz dodatkowo wraz z pierwszą klasą dodatkowe 50% mil. Możliwym do zastosowanym algorytem kolejkowania jest WFQ.
Nowością jest również możliwość implementacji komunikacji typu multicast, wymaga ona jednak sklonowania gołębią. Z dokumentu dowiadujemy się również, że średni TTL dla gołębi wynosi 15lat oraz o proponowanym rozszerzeniu standardu również na pingwiny jednak bez powodzenia (nie latały).
RFC 5514 IPv6 over Social Network
1 kwietnia 2009 został opublikowany eksperymentalny protokół IPoSN mający na celu znacząco podnieść ilość dostępnych routerów wykorzytujących IPv6. Jak słusznie zauważył autor Eric Vyncke nowy standard IP nie był – nadal w sumie nie jest – w powszechnym użyciu w przeciwieństwie do mediów społecznościowych. Do głównych założeń architektonicznych należy:
- Każdy użytkownik portalu społecznościowego posiada przynajmniej jeden adres IPv6 loopback oraz pełni funkcję routera
- Każdy znajomy lub osoba z która nawiązaliśmy kontakt stanowią połączenie punkt-punkt
Wykorzystując fakt, że większość użytkowników social media posiada rozbudowaną sieć kontaktów tworzy to idealne warunki dla implementacji topologii typu mesh (wiele połączeń pomiędzy rożnymi końcówkami). Zalecanym protokołem routing jest RIPng ponieważ jest względnie odporny na jitter(nierównomierne opóźnienie pomiędzy pakietami w transmisji) oraz nie rozsyła wszystkich informacji o zmianach w topologii do swoich sąsiadów.
IPoSN doczekał się swojej implementacji w postaci aplikacji na facebooku – IPv6overFacebook – niestety jest już ona usunięta.
RFC 5841 TCP Option to Denote Packet Mood
Typowe pakiety IP zostały stworzone w celu przenoszenia danych i nie są w stanie odczuwać emocji. Jednakże skoro w codziennej komunikacji wielu z nas używa emotikonek dlaczego nie udostępnić by takiej możliwości datagramom? Dokładnie na ten sam pomysł wpadło dwóch członków IETF Richard Hay oraz Warren Turkal w 2010. Dzięki tym gentleman już teraz możemy oznaczyć pakiet który jesteśmy zmuszeni reatransmitować po raz kolejny jako „wściekły”. Technicznie rozwiązano to jako implementacja pola opcji w nagłówku TCP z wykorzystaniem wartości 25 do oznaczania zmiennej jako przekazywana emocja. Pole pozwala na użycie 4-5 bajtów
Zaproponowane kodowanie znaków w ascii:
Binarnie Dec Hex Znaki
======== === === =====
010 0101 37 25 %
010 1000 40 28 (
010 1001 41 29 )
011 1010 58 3A :
011 1011 59 3B ;
011 1110 62 3E >
100 0000 64 40 @
100 0100 68 44 D
100 1111 79 4F O
101 0000 80 50 P
110 1111 111 6F o
111 1100 124 7C |
ASCII Emocja
===== ====
:) Happy
:( Sad
:D Amused
%( Confused
:o Bored
:O Surprised
:P Silly
:@ Frustrated
>:@ Angry
:| Apathetic
;) Sneaky
>:) Evil
RFC 3251 Electricity over IP
Posiadanie dwóch osobnych sieci zamiast jednej zawsze prowadzi do zwiększonej biurokracji i dodatkowych kosztów. Dlaczego by zatem nie przesyłać elektryczności z wykorzystaniem istniejącej sieci IP? Do tego celu 1 kwietnia 2002 roku
Bala Rajagopalan zaproponował MPLampS: Mostly Pointless Lamp Switching.
Terminologia użyta w dokumencie:
- LSR: Load-Switching Router – Urządzenie stosowane w sieci core MPLampS.
- RSVP: Rather Screwed-up, but router Vendors Push it – Protokół sygnalizujący.
- RSVP-TE: RSVP with Tariff Extensions – Adaptacja RSVP w sieci MPLampS, do wykorzystania w przypadku stosowania różnych taryf.
- CRLDP: for CRying out Loud, Don’t do rsvP – Konkurencyjny do RSVP protokół sygnalizujący.
- OSPF: Often Seizes-up in multiPle area conFigurations – Hierachiczny protokół routingu.
- ISIS: It’s not oSpf, yet It somehow Survives – Kolejny protokół routingu.
- VPN: Voltage Protected Network – Pozwala klientom z wieloma lokalizacjami na otrzymywanie energii elektrycznej o znikomej fluktuacji napięcia z powodu zakłóceń od innych klientów.