[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ND-proxy applicability and loop-prevention

Hi Ralph,

Ralph Droms wrote:

> I reread draft-thaler-ipv6-ndproxy-02.txt, and wonder if it might be 
> time to
> revisit the need for ND proxies.

Yes, I have been wondering the same thing - perhaps not for exactly
the same reasons.

> It seems the primary motivation for ND proxies is to avoid the need 
> for L3
> devices that require configuration, prefix assignment and 
> configuration.  I
> read the two scenarios in section 1, and, more generally, the 
> motivation for
> ND proxies to provide bridging between links with dissimilar 
> technologies,
> as motivation for the use of one ND proxy between a single upstream link
> (perhaps to a service provider) and one or more local networks.

When you say "one or more local networks", are you intending to imply the
possibility of multiple logical IP subnets within the local network or 
are you
really meaning to say "one or more bridged segments of the local network" in
a "flat" topology? (I guess "either/or", or "both/and" would also be 
answers.) Didn't ATM and NBMA networking specify the concept of Logical
IP Subnets (LIS) - and what has been the operational experience with
deployment of multiple LISs within a site?

> In the case of a more complicated local topology, it seems to me that it
> would be highly unusual to find dissimilar link technologies that require
> the use of ND proxies.  Why would anything but bridgeable IEEE802 be used
> among the local networks?

Well, we bump into the path MTU issue yet again in this case. Your local
network might have media that configures a linkMTU quite a bit smaller
than the IPv6 minMTU of 1280 bytes, e.g., I think IEEE 1394 fits this space,
and RFC 3150 goes into other examples of such MTU-constrained media.

Classical L2 bridging would say that packets too large to be forwarded
onto the target segment should be dropped silently - resulting in an instant
Path MTU black hole in this case.

NDProxy tried to address this by asking the proxies to send ICMPv6
"packet too big" messages instead of just silent-drop. But, there are
two issues with this:

  1) ICMPv6 "packet too bigs" are not permitted to report a linkMTU
    of less than the IPv6 minMTU
  2) Being able to send the ICMPv6's requires the ability to parse the L3
    information in the packet and in some instances (e.g., when IPv6 header
    compression is used, when security transformations are used, etc.) the
    L3 information might not be available.

This leaves us with the option of an L2 adaptation method of some sort.
Jeff Mogul spoke well of this approach in his landmark: "Fragmentation
Considered Harmful" paper, and it indeed seems to have been the approach
adopted by ATM among others. The idea is that the device at the head of
the segment with the restricting MTU fragments the packet and the device
at the receiving end reassembles it. The trouble is, widely-deployed 
media (e.g., IEEE 802) may not have such an L2 adaptation scheme built-in
and it's too late to go out and do a wide-scale recall now. Even if we could
do such a recall, and new L2 media with mechanisms to support the
adaptation were deployed, it would be unrealistic to expect network
middleboxes that terminate media segments to do the reassembly due
to state scaling issues.

The good news is that there is a clean-and-simple way of getting the L2
adaptation we need when sending IPv6 packets over a network that might
bridge heterogeneous technologies: always use IPv4 as the L2 media to carry
IPv6 via IPv6-in-IPv4 tunneling (*) and let the bridges (or, IPv4 
routers as the
case may be) do IPv4 fragmentation. Then, the L2 adaptation scheme comes
pre-configured in the guise of IPv4 fragmentation, and the reassembly always
takes place at the tunnel decapsulator at the egress edge of the bridged 

(*) When the IPv6 neighbors can be assured that bridging of dissimilar
    media is not taking place, they can use native IPv6 instead of tunneled.

> We've done the hard engineering work in specifying DHCPv6 to solve the
> problem of configuration and prefix delegation for a single gateway 
> device
> that has an upstream PPP, cable or wireless connection and multiple
> downstream local networks.  DHCPv6 PD is a published standard with 
> multiple,
> interoperable implementations.  It is available in simple home gateways,
> equivalent to the IPv4 NAT device in my basement.  I don't see a 
> compelling
> requirement to invent something new. 

Denpending on how you answered my earlier question, can it be said that
the DHCPv6 Relay would be the correct mechanism for deployment at
the edges of LISs within the local network?


> - Ralph
> At 09:16 PM 3/23/2004 +0200, Jari Arkko wrote:
>> Hmm.... I thought the idea of ND proxies was to avoid a complicated
>> L3 device. If we need something like a routing protocol, maybe
>> its time to pull out the proxy thing and replace it with a real
>> L3 device?
>> --Jari
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6