[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: mech-v2-05pre
Pekka,
I thought about it more, and the only way a decapsulator should be able
to receive an encapsulated packet with version = 6 and length less than 40
is if the act of encapsulation itself were the source of the truncated packet
(or, if the packet were somehow truncated in the IPv4 network). Reason is
that truncated packets would be discarded by IPv6 long before ever reaching
the encapsulator's IPv6-in-IPv4 tunnel driver. Some implementors might see
this as reason for sending an ICMPv4 error, so if we want it to be "drop silent"
this needs to be clarified.
About versions other than 6, if you want to argue that having something
other than 6 is an error, then that would suggest sending some sort of
error message - but it's not clear exactly what kind of error could be sent?
(ICMPv6 "parameter problem"? Some kind of ICMPv4? Other?)
Aside from this, I think we are both correct to a certain degree but for the
above reasons I believe my text suggestion is better. Here it is again:
"If the version encoded in the first 4 bits of the encapsulated packet
is "6", and the payload is not at least 40 bytes in length (i.e., the
minimum IPv6 packet), the packet MUST be silently discarded. Further
processing for packets with version other than "6" is out of scope."
Fred L. Templin
Pekka Savola <pekkas@netcore.fi> wrote:
On Thu, 26 Aug 2004, Fred Templin wrote:
> Drop silently? Drop and send an ICMPv4 error? Drop and send
> an ICMPv6 error? Drop and do something else? By specifying
> drop here, the behavior needs to be clearly spelled out to
> avoid interoperability issues.
It should be obvious that it's "silent discard" but that can be
spelled out if necessary.
> It seems both unambiguous and correct to say that if the version
> is "6" and the payload is not at least 40 bytes, the packet MUST
> be silently discarded. (Reason: there is no error from the IPv4
> perspective, and there is not enough information to construct an
> ICMPv6 error.) The same cannot be said for versions other than
> "6", which argues for declaring out of scope.
I can't see your point. Protocol-41 is meant to transport *IPv6*
packets -- that's
why it's protocol 41. Your point would be valid (I
think) if we were specifying a more generic tunnel (like GRE), which
doesn't specify the protocol of the inner payload, but we aren't.. so
it seems fair to say that anything in the payload that's not IPv6 is
an error, and must be dealt with (and it's just a question where it's
specified clearly enough who needs to deal with it).
Again, this doesn't matter in practice at all (AFAICS) unless one
intents to devise a new IP protocol almost exactly like IPv6 which
must be tunneled across unmodified protocol-41 configured tunnel
implementations.
FWIW, I personally understand Vlad's concern that checking is really
the job of the IPv6 code, not the "Layer 2" code, but in this case 1)
when tunnels have a bigger chance of transmitting bogus packets, 2)
the protocol-41 already specifies that the content is IPv6, and 3) we
already specify a lot of check in the layer 3 contents, this
should
not be a big issue to make sure that the implementor doesn't forget to
check the version & length.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings