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

Re: ND-proxy applicability and loop-prevention

Hi, Fred...

At 02:00 PM 3/23/2004 -0800, Fred Templin wrote:
>Hi Ralph,
>Ralph Droms wrote:
>>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?

Here's the topology I'm thinking of:

devices    link            <-customer|service provider->
-------    ----

phone\  /---------\
phone/  \---------/ \
                      \  +-------+                +------+
  host\  /---------\   --|gateway|                |access|
       +-|  data   |-----|router |----------------|router|
  host/  \---------/   --|       |                |      |
                      /  +-------+                +------+
    TV\  /---------\ /
       +-|  video  |/
    TV/  \---------/

The customer gateway router uses DHCPv6 PD to obtain the customer prefix
(/48? or longer?) from the access router.  The gateway router assigns /64s
to its downstream links.  Each of the downstream links is a physical link.
I use separate links for telephony, data and video just as an example that
I've heard used by service providers.

>>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.

Sounds to me like a hardware problem.  Why should we try to hack a solution
into IPv6?  But that's my off-the-cuff answer.  I'll review IEEE 1394 and
read RFC3150.

>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 physical
>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.

When are you suggesting the use of IPv6-in-IPv4 tunneling?

>>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?

I don't quite understand: DHCPv6 relay for what function?

>>- 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?
>>>IETF IPv6 working group mailing list
>>>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>>IETF IPv6 working group mailing list
>>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6

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