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