Subject: RE: ND-proxy applicability and loop-prevention

From: "Christian Huitema" <[email-masked]>
Date: Tue, 23 Mar 2004 10:32:08 -0800

> One easy way to do this would be define a special multicast group,
> to which all routers will listen, thus parse and forward these
> packets to their uplinks. The packet would contain the primary
> identification of that host and the uplink over which the packet
> gets sent, one could include a 'trace' of where the packet passed
> to aid in further diagnosis. When a router gets a packet containing
> it's own ID it can use the link field contained in the packet to
> see where it sent the packet too and then simply disable that link
> from being used for forwarding packets too, notifying the admin
> in some way or another. This at least prevents the loop from
> happening for too long and thus minimizes damage.

There are essentially two ways to break loops: either by using a
"routing protocol" of some kind that imposes a correct routing structure
on the set of proxies; or by using a form of "loop detection" option in
the ND messages. The spanning tree algorithm is an example of the first
class of solution; we could also conceivably use RIP or OSPF with host
entries.

I looked at the second class of solutions in a now expired draft. The
basic idea is to add a "forwarded by" option in the discovery messages
sent by the proxy, and to use that option to detect loops, either with a
hop limit (don't forward more that N times) or with a packet inspection
(don't forward what you have already forwarded once).

The routing or spanning tree solution is the most transparent to the
hosts, since it does not change any byte in the ND packets. However,
transparency may not be entirely desired, since SEND requires being
fairly explicit about relays. The "forwarded by" option is perhaps more
powerful, as it allows for real-time discovery of alternate paths. 

-- Christian Huitema

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Jari Arkko <[email-masked]>
Date: Tue, 23 Mar 2004 21:16:28 +0200

Christian Huitema wrote:

> fairly explicit about relays. 

Yes. In fact, an explicit marker telling that there indeed
was a proxy would be quite useful for SEND.

Fred Templin wrote:

> In other words, we need something like the experimental protocols
> coming from the MANET wg (e.g., AODV, DSR, OLSR, TBRPF).
> Even better would be a unified mechanism that combines the best
> aspects of on-demand and reactive protocols. 

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

---

From: Fred Templin <[email-masked]>
Date: Tue, 23 Mar 2004 11:38:35 -0800

> was a proxy would be quite useful for SEND.

The concern here is that the explicit marker may need to be carried
in all packets (not just ND packets) if there are asymmetric paths,
or if paths can change dynamically after the initial  ND exchange.

> its time to pull out the proxy thing and replace it with a real

I did not say "L3 device", nor did I intend to imply such. While some of
the protocols I was referring to include extensions for passing around L3
prefix information, their primary function is to establish host routes based
on information learned from neighbors, and this can happen based on
either L3 addresses or L2 addresses as node IDs. In fact, the correct target
domain of application in this context would seem to be as a replacement
for the IEEE 802.1D spanning tree, so L2 addressing would seem to be
indicated.

Fred
[email-masked]

---

From: Ralph Droms <[email-masked]>
Date: Tue, 23 Mar 2004 15:32:32 -0500

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

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.

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?

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.

- Ralph

---

From: Fred Templin <[email-masked]>
Date: Tue, 23 Mar 2004 14:00:49 -0800

Hi Ralph,

> revisit the need for ND proxies.

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

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

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

> 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-masked]

---

From: Ralph Droms <[email-masked]>
Date: Wed, 24 Mar 2004 13:51:51 -0500

Hi, Fred...

At 02:00 PM 3/23/2004 -0800, Fred Templin wrote:
>[...]
>possibility of multiple logical IP subnets within the local network or are you

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.

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

>at the receiving end reassembles it. The trouble is, widely-deployed physical
>IPv6 via IPv6-in-IPv4 tunneling (*) and let the bridges (or, IPv4 routers 
>as the

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

>the edges of LISs within the local network?

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

---

From: Fred Templin <[email-masked]>
Date: Wed, 24 Mar 2004 11:32:41 -0800

Hi Ralph,

A few quick follow-ups appear below:

> devices    link            <-customer|service provider->

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.

> into IPv6?  But that's my off-the-cuff answer.  I'll review IEEE 1394 and

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

>> takes place at the tunnel decapsulator at the egress edge of the 
>> bridged network.
>>

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

> 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-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 24 Mar 2004 14:21:12 -0800 (PST)

> class of solution; we could also conceivably use RIP or OSPF with host

And RBridges argues that one can do this without any changes on
hosts or routers; they see the same behavior as without the
RBridges even though the RBridges use a routing protocol (on L2 and/or
L3 addresses) between eachother.

> (don't forward what you have already forwarded once).

If one were do to a loop detection scheme something like that would make sense.
> powerful, as it allows for real-time discovery of alternate paths. 

I guess I don't understand the need for explicit relays.
SEND works over existing L2 bridges - it can't even see that they are there.
(As a result there are L2 derived security issues - you can "redirect"
things at L2 unless L2 is somehow secure.)
I guess I don't understand the tradeoffs between running SEND over
a larger transparently "bridged" LAN vs. using "relays" that are
visible to SEND.

  Erik