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

[RJ Atkinson <[e-mail]>]

On 31  May 2012, at 11:50 , Fernando Gont wrote:
> On 05/31/2012 12:16 PM, Ronald Bonica wrote:
>> 1) Hosts MUST NOT fragment ICMPv6 Router Solicitation, Router
>> Advertisement, Neighbor Solicitation, Neighbor Advertisement or
>> Redirect messages.
> 
> This one is correct.
> 
> Note that in draft-gont-6man-nd-extension-headers, we're currently
> saying "SHOULD NOT", but this should probably be changed to "MUST NOT",
> as you indicate.

Agree.  

"MUST NOT" seems to be functionally necessary here.

>> 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.
> 
> This is correct.
> 
> We have expressed this requirement (in
> draft-gont-6man-oversized-header-chain-01.txt) as:
> 
>   All IPv6 packets MUST contain the entire IPv6 header chain within the
>   first "assumed Path-MTU" bytes of the packet.  If a packet is
>   fragmented, the first fragment of the packet (i.e., that with a
>   Fragment Offset of 0) must contain the entire IPv6 header chain
>   within the first "assumed Path-MTU" [RFC1981] [RFC4821] bytes of the
>   packet.

That seems OK at first reading.  

I hope there already is text that has the effect of requiring 
a receiving IPv6 node to drop any received ICMPv6 that hid 
behind a Fragment Header.  One imagines the actual requirement 
for receiving IPv6 nodes might be written more generically.

As an example to clarify things, it would not hurt to explicitly 
note that this does NOT preclude the use of TCP Jumbo data payloads, 
but instead merely requires that all *headers*, starting from IPv6 
base header and continuing up to & including the TCP header, 
be present in the 1st packet.

This means that the RA Guard document ought to:
(1) cite (normatively) draft-gont-6man-oversized-header-chain, 
(2) delete Rule 4 of the RA Guard draft (which is not needed), 
and 
(3) add clarifying text to the RA Guard draft noting that the 
    referenced 6MAN document ensures that RA messages that 
    try to hide behind a Fragment Header will be dropped 
    by the receiving IPv6 node.


Yours,

Ran