On 19-jul-2007, at 1:15, Ole Troan wrote:
Then you will fail in cases like the one I noted above, and you
won't be
RFC compliant. RFC2461 requires NUD on _all_ links. (I don't think
anyone is arguing it doesn't.)
as long as we also agree that it is perfectly valid to operate p2p
links
with NUD turned off.
This is a strange discussion.
People have different opinions about what behavior makes sense. I can
follow the reasoning behind most of them. But the notion that an
implementation should just do what the implementation thinks is best
without checking with the other side is BAD. As someone else said, we
lived through that with SLIP and we fixed it for IPv4 with PPP. The
PPP way of handling these things is by negotiating during the *CP
phase, NOT blindly assuming facts not in evidence.
The discussion about whether neighbor discovery is useful is mostly a
rathole. Neighbor discovery isn't the problem on a true point-to-
point link. The real question is: what about router advertisements?
Should they be sent and should they be expected?
But even THAT is not the biggest problem with IPv6 over PPP. Unless
you're dealing with dial-up, the PPP link will more often than not
terminate on a (home) router, which means that you not only need a
subnet for the PPP link delegated by the router at one end of the
link, but also a prefix that can be used on the LAN behind the router
that terminates the PPP link on the opposite side.
In my opinion, we should either say that PPP is just another
multicast-capable link technology which means that we do vanilla ND,
NUD, DAD, RAs and DHCPv6 prefix delegation, OR we say PPP is a
special case, throw out all that stuff we use on ethernet and specify
IP6CP options that implement the functionality that is relevant over
a point-to-point link under common point-to-point constraints (i.e.,
low bandwidth, high delay, often operating on battery power).
Mixing the two approaches can only lead to even more interoperability
problems down the road. In my book I tell people to forget about IPv6
over PPP because it's pretty much impossible to make it do something
useful in the real world. It would be great if I could remove that
little piece of advice in a future edition.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
