Wymagania IP

• Musi implementować IP oraz ICMP
  Tak: Klasa IP implementuje protokół IP, natomiast klasa ICMP -- protokół ICMP.
• Musi obsługiwać zdalny węzeł z wieloma adresami w warstwie aplikacji
  Tak: Oprogramowanie protokołu nie zdaje sobie sprawy z faktu wymiany informacji ze zdalnym węzłem z wieloma adresami ani też nie wspiera takiej komunikacji realizowanej przez aplikację.
• Może wspierać lokalny węzeł z wieloma adresami
  Częściowo: Węzeł może posiadać tylko jeden interfejs sieciowy (założenie projektowe), rutery moga posiadać wiele interfejsów, a przez to wiele adresów IP.
• Musi udostępniać przełącznik cechy rutera (ang. embedded router functionality). Standardowo musi być on ustawiony na operacje węzła.
  Częściowo: Klasa maszyny determinuje zdolność do rutowania pakietów (nie ma możliwości bezpośredniej zmiany w trakcie działania programu).
• Nie wolno odblokowywać rutowania w oparciu o liczbę interfejsów
  Tak: Jedynie obiekty klasy ruter ma możliwość rutowania.
• Powinna być zapamiętywana informacja o odrzucanych datagramach, włączając w to zawartość datagramu, zdarzenie oraz wartości statystyk
  Częściowo: PROTONET nie udostępnia mechanizów zapamiętywania zawartości odrzuconych datagramów, jednak utrzymuje statystyki.
• Musi po cichu odrzucać odebrane datagramy, których numer wersji IP jest różny od 4
  Tak: Wymaganie to zostało zaimplementowane.
• Musi być sprawdzana suma kontrolna, a jej błąd powoduje ciche odrzucenie datagramu
  Tak: Datagram o błędnej sumie kontrolnej^3.2 jest odrzucany.
• Musi przesyłać pakiety, w których adres źródłowy jest własnym adresem IP węzła
  Tak: Oprogramowanie IP zawsze ustawia adres źródłowy wychodzącego pakietu.
• Musi po cichu odrzucać datagramy nie przeznaczone dla danej maszyny
  Tak: Jeżeli system nie został skonfigurowany jako ruter, oprogramowanie IP odrzuca te datagramy, które nadeszły z błędnym adresem docelowym.
• Musi po cichu odrzucać datagramy z błędnym adresem źródłowym (adres inny niż pojedynczy)
  Tak: Adres źródłowy jest kontrolowany przed przekazaniem datagramu do wyższych warstw.
• Musi wspierać gromadzenie
  Tak: Fragmenty pakietów są gromadzone w celu ich defragmentacji.
• Może zachowywać to samo pole ID w identycznych datagramach
  Nie: Wszystkim wychodzącym datagramom nadawane są kolejne numery ID.
• Musi pozwalać warstwie transportu na ustawienie TOS
  Tak: Oprogramowanie IP akceptuje każdą wartość TOS ustawioną przez oprogramowanie wyższych warstw.
• Musi przekazywać odebrane TOS do warstwy transportu
  Tak: Oprogramowanie IP udostępnia cały nagłówek IP wyższym warstwom.
• Nie wolno wysyłać pakietów, których TTL ma wartość 0
  Tak: Metoda IP::ipSend nie wysyła pakietów o zerowej wartości TTL.
• Nie wolno odrzucać pakietów, których TTL jest mniejsze niż 2
  Tak: jeżeli system jest punktem przeznaczenia pakietu, to pakiet jest akceptowany bez względu na wartość TTL. TTL jest sprawdzane (porównywane z zerem) tylko wtedy, gdy pakiet jest przekazywany dalej.
• Musi umożliwić warstwie transportu ustawienie TTL
  Tak: Jednym z parametrów metody IP::ipSend jest TTL.
• Musi być możliwa modyfikacja stałej wartości TTL
  Nie: Wartość ta jest zaszyta jako stała w oprogramowaniu (niedużym kosztem można to zmienić i udostępnić ją do edycji jako parametr maszyny).
• Może po cichu odrzucać datagramy przeznaczone dla interfejsu innego niż ten, który je odebrał
  Tak: Datagramy takie są odrzucane przez oprogramowanie IP.
• Implementacja opcji IP
  Nie: Opcji IP nie zaimplementowano -- na obecnym etapie rozwoju systemu były one zbędne (brak mechanizmów, które byłyby je w stanie wykorzystać).