Bridging dissimilar media with NDproxy (was Re: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt)

[Fred Templin <ftemplin@iprg.nokia.com>]

Erik et al,

Erik Nordmark wrote:

> Odd - when I was in the IPv6 WG last week there was some discussion
> about the fact that ndproxy and SEND can not be made to work together.
> (Conclusion seems to be that proxy NA can be secured using SEND in the case
> where there is a trust relationship between the host and the proxy, but
> there is no such relationship in ndproxy hence it can not be secured.)
> The odd thing is that there wasn't a groundswell reaction in the IPv6 WG saying
> "we really need ndproxy - how do we get SEND fixed" - there seemed to be
> almost complete disinterest in ndproxy as far as I could tell.

Diverting just a bit from the main focus of discussion, another feature
introduced by ND proxying is that the NDproxies can support the path MTU
discovery process when bridging between dissimilar media - this is something
you don't get with  simple L2 bridging. The question I raised at the 
microphone
is whether the currently-specified ICMPv6 "packet too big" message approach
could be trusted, and this morphed into the wider "NDproxy/SEND 
interactions"
discussion referred to in this thread. But, the more specific question I 
didn't get
the chance to ask was whether the ICMPv6 "packet too big" message approach
is the best way to go in the first place?

As has always been the case, the choices for L2 bridges are: 1) silently 
drop
too-big packets (i.e., simple L2 bridging), 2) look into the L3 header 
and send
PMTU feedback (e.g., ICMPv6 "packet too bigs") as necessary, 3) look into
the L3 header and perform L3 fragmentation as necessary, or 4) perform
link-specific fragmentation and reassembly. Option 1) has the disadvantage
of no PMTU feedback and thus cannot be used for bridging dissimilar media
due to PMTU black holes. Option 2) has the disadvantage of unreliable 
delivery
of untrusted ICMPs, but even worse is the fact that the L3 header may not be
available for inspection in all cases yielding the same broken PMTU behavior
as for simple L2 bridging. Option 3) does not even work for IPv6, since
middleboxes are not allowed to perform IPv6 fragmentation.

Option 4) on the other hand has precedence in existing technologies (e.g.
IEEE 802.11), is recommended by analytical works such as "Fragmentation
Considered Harmful", and would seem like a reasonable alternative as long
as it is well implemented and does not impart excessive delay/delay 
variance.
It is only practical when reassembly takes place at the egress node at 
the edge
of the bridged network (and not an L2 middlebox), but this is exactly 
the case
when IPv4 is used as the L2 for IPv6. In other words, when IPv4 
fragmentation
is used as the link-specific fragmentation/reassembly mechanism the 
fragments
not lost in the network will arrive at the same IPv6/IPv4 tunnel 
decapsulator.

Essentially, I see advantages for NDproxy over simple L2 bridging *if*
the  NDproxies are specified to use link-specific fragmentation (i.e., IPv4
fragmentation) whenever possible rather than always trying to send ICMPv6
"packet too bigs". Since the NDproxy has no way of knowing the size of the
reassembly buffer in the decapsulator, IPv4 fragmenation could only apply up
to the minimum MRU required for all decapsulators, which I believe [MECH]
currently sets at 1500bytes.

For too-big packets larger than 1500bytes, the NDproxy could still send
the ICMPv6 "packet too bigs" and hope for the best - but IPv6/IPv4
encapsulators would be well-advised to limit the size of the IPv6
packets/fragments they send to 1500bytes (or even smaller - down to
1280 bytes - if L2 encapsulatons might occur along the path) due to the
PMTU black hole issues described above.

Fred
ftemplin@iprg.nokia.com

P.S. Adding Dave and Chirayu to the Cc: list to get this on the NDproxy
   issue tracker. (Issue is "NDproxy should use IPv4 fragmentation for
   IPv6/IPv4 encapsulated packets no larger than 1500 bytes").