Re: draft-savola-v6ops-firewalling-01.txt

[Pekka Savola <pekkas@netcore.fi>]

Thanks for comments.

On Sun, 16 Mar 2003, Jun-ichiro itojun Hagino wrote:
> >2.2. Possible Solutions
> >
> >   The correct behaviour must be made clear; the wording should be
> >   clarified.  Clarifications might be needed at least on:
> >
> >      1. whether intermediate nodes should be taken into account in the
> >         text describing the header processing
> >
> >      2. intermediate nodes' behaviour when detecting unrecognized
> >         headers
> 
> 	do we have such document/consideration (packet processing at
> 	intermediate nodes, like firewalls) in base IPv4 specification?
> 	as far as I know, no.  

Well, depends on what you want.  For example, in RFC791 there is no text 
that *forbids* it and in IP options there is:
=====
    The copied flag indicates that this option is copied into all
    fragments on fragmentation.

      0 = not copied
      1 = copied
=====
.. which would heavily imply that a router (=intermediate node) is 
supposed to in fact process the packet, modify it, etc.

The situation in IPv6 is slightly different wrt. intermediate nodes as 
RFC1812 states:

4.2.2.6 Unrecognized Header Options: RFC 791 Section 3.1

   A router MUST ignore IP options which it does not recognize.  A
   corollary of this requirement is that a router MUST implement the End
   of Option List option and the No Operation option, since neither
   contains an explicit length.

but host reqs RFC1122 says:

                                                              The IP
            and transport layer MUST each interpret those IP options
            that they understand and silently ignore the others.

.. so the behaviour seems to be unspecified as there are no fields like 
these which would trigger a response from hosts but not routers.

>                           therefore, i guess we should try to "clarify"
> 	it outside of base IPv6 spec, if we are to do it.  it is not IPv6
> 	base spec's fault that it does not cover behavior of firewalls.

This case is probably applicable to most middleboxes etc. too, but I tend 
to agree that changing RFC2460 in the spec is not an option.

A clearer case of true ambiguity is the use of option starting wiht "11" 
(ie. send back ICMP) with _hop-by-hop_ option, which are to be processed 
by every node on the path.  At least for this particular option, the 
intent is that routers/etc. will send ICMP's out if something unrecognized 
is noticed, but that's not crystal clear..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings