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

Re: ND-proxy applicability and loop-prevention

Hi Ralph,

A few quick follow-ups appear below:

Ralph Droms wrote:

> 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 
>> reasonable
>> 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\  /---------\
>       +-|telephony|\
> 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.

OK, but I don't expect this would be the only configuration encountered
in practical deployments. I'm thinking that integrated voice/video/data
would be multiplexed over a common infrastructure in many cases.

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

Not suggesting any solution for IPv6 because there is none. Any L2
bridge that connects media with dissimilar MTUs and does silent-drop
will cause PMTUD black holes that cannot be detected as anything other
than loss due to an indeterminant reason. So, I have to believe that such
L2 bridges probably don't exist in wide-scale deployment (although I
know of some that were around a couple of decades ago).

>> 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 network.
>> (*) 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?

When the neighbor does not respond to native (i.e., non-tunneled)
IPv6 ND messages.

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

The relay provides the edge of the broadcast domain for service discovery.
In other words, when a node within the LIS boots up and has no configuration
information, it can send a broadcast/multicast service discovery message
which will hopefully be flooded within the LIS but no further. (The relay
can then forward the service discovery message on to the server if 

Some of these recent "flooding" proposals from the MANET wg might
be useful for this. Then again, there might alread be some existing
mechanisms, e.g., something from the ZEROUTER wg. Would
welcome any pointers to doc's you think I should read, but will
go check on my own in the meantime...

Thanks - Fred

>> Fred
>> ftemplin@iprg.nokia.com
>>> - 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
> 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