Alexandru Petrescu writes:
> If a ppp peer negotiates an Interface ID and puts it in the Neighbour
> Cache attached to the ppp0 entry, won't break anything. When displaying
> the NC the entry simply won't show up empty.
Yes, it will break something.
- Such a system will send Neighbor Advertisements that include the
Target link-layer address option. If that message is sent to a
peer that does *not* include this 'feature', then, from the peer's
point of view, the option will include a bogus hardware address.
The result is likely a loss of connectivity, as the peer may try
(unsuccessfully) to send to a link-layer address that doesn't
exist.
- Such a system will receive Neighbor Advertisements from its peer
that do not include the Target link-layer address option. What
will it do? Per section 7.2.5 of RFC 2461, and because the system
mistakenly believes that point-to-point links have L2 addresses,
it will just *DISCARD* those messages, and will never attain
REACHABLE state. Again, that leads to a loss of connectivity.
The latter of those two seems crucial to me.
Worse still, the ID numbers you're talking about are negotiated by
PPP. This means that both ends of the link are already keenly aware
of the ID numbers in use. It serves no purpose whatsoever to have the
peers telling each other something that they already know. It's a
solution off in search of a problem.
> If same ppp peer declares that ppp0 interface nd-capable (instead of
> currently declared nd-non-capable),
I'm not sure what you're talking about here. There's no such
"nd-capable" feature in the system I work on. In fact, I suspect
having such a feature may be a design flaw, as RFC 2461 makes it
pretty clear that ND is supposed to run on all links using IPv6.
> and builds a virtual ll header
> structure whose format is (src, dst on 64bits)
Virtual LL header? I don't know what that is.
> and then declare some
> other constants for special ll multicast addresses then that ppp peer
> won't crash. The issue is what to declare on the other ppp peer.
>
> By existing ND implementations I assume it's meant ND over an ll-full
> (an interface with link-layer address). I think that as long as the
> ND/ptp enhancements are applied only on ll-less interfaces that can
> generate an IID then the other interfaces' implementations (eth, tun,
> etc) won't be affected. No?
That part is correct. Non-point-to-point interfaces are not affected
by your proposal.
But I believe interoperability for existing point-to-point systems is
destroyed.
> >> An "Interface ID" is exactly what ND needs on a ppp link.
> >
> > Disagree. Why does it need _any_ link layer address? Why should it
> > care?
>
> A main ND's goal is to resolve the IP address into a ll address, so if
> there's no ll address then no need of ND exchanges (especially no need
> of NS/NA).
Actually, ND does more than that. It verifies that the peer actually
has the IPv6 address in question. If it doesn't have that address,
then it doesn't respond, and you end up with an unreachable
destination. This is part of the "unreachability detection" logic.
It also has at least one "special" feature, which is the "R" bit.
Peers can detect which one (or both) is a router.
> At which point it would be difficult to say that ND runs
> over ll-less addresses ok. I think.
I disagree. The current RFC makes clear provisions for links (such as
point-to-point links) that lack link-layer addressing. I think
implementations should follow the current RFC advice.
I do agree that ND has only somewhat marginal value on point-to-point
links, but I don't think that implies that it should now be changed in
an incompatible manner.
--
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
