Re: [v6ops] Last Call: <draft-ietf-v6ops-ra-guard-implementation-04.txt> (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice

[Ronald Bonica <[e-mail]>]

Fernando,

If I read what you are saying correctly, our request to 6man should say:

1) Hosts MUST NOT fragment ICMPv6 Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement or Redirect messages.

1) Hosts MUST NOT fragment any other ICMPv6 message unless the IPv6 header, all extension headers, the ICMPv6 type, code, and checksum are included in the first fragment

3) Hosts MUST NOT fragment packets carrying any next-layer protocol unless the IPv6 header, all extension headers, the entire next-layer protocol header are included in the first fragment. TCP and UDP are examples of next-layer protocols.

Do I have this right?

                                      Ron


> -----Original Message-----
> From: Fernando Gont [mailto:[e-mail]]
> Sent: Thursday, May 31, 2012 10:55 AM
> To: Ronald Bonica
> Cc: Fernando Gont; RJ Atkinson; [e-mail]
> Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-ra-guard-
> implementation-04.txt> (Implementation Advice for IPv6 Router
> Advertisement Guard (RA-Guard)) to Best Current Practice
> 
> Hi, Ron,
> 
> On 05/31/2012 10:53 AM, Ronald Bonica wrote:
> > The problem that we are wrestling with isn't specific to RA Guard.
> 
> We're kind of discussing to different, but entangled, problems:
> 
> a) Use of fragmentation in Neighbor Discovery
> b) IPv6 header chains that span multiple fragments
> 
> 
> Regarding "a)", use of fragmentation with ND prevents feature-parity
> with IPv4: It becomes virtually impossible to e.g. perform Neighbor
> Discovery inspection (a la arpwatch or the like)
> 
> Regarding "b)", it essentially prevents stateless filtering, and also
> breaks stateless translators. And is not limited to ICMPv6, but to all
> traffic. (please see below)
> 
> 
> > Therefore, we might want to request the following from 6man:
> >
> > 1) Hosts MUST NOT send fragmented ICMPv6 packets unless the IPv6
> > header, all extension headers, the ICMPv6 type, code, and checksum
> are
> > included in the first fragment
> 
> This is a subset of "2)" below. Additionally, if you still allow
> fragmentation, ND inspection (i.e. inspection of the ND packets
> contents) is still virtually impossible -- and fragmentation is not
> needed for ND, anyway. So one can safely forbid fragmentation with ND
> (for the general case).
> 
> This is why I wrote
> <http://tools.ietf.org/id/draft-gont-6man-nd-extension-headers-02.txt>
> 
> 
> 
> > 2) Hosts MUST NOT send fragmented packets carrying any next-layer
> > protocol unless the IPv6 header, all extension headers, the entire
> > next-layer protocol header are included in the first fragment. TCP
> and
> > UDP are examples of next-layer protocols.
> 
> Fully agree. For instance, that's why we wrote:
> <http://tools.ietf.org/id/draft-gont-6man-oversized-header-chain-
> 01.txt>
> 
> My take is that these "packets with an IPv6 header chain that spans
> multiple fragments" will be unreliable in the public Internet
> (stateless firewalls and stateless translators).
> 
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: [e-mail]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
>