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