JAmes, yes, it's a solution in search of a problem. There are problems
in search of solutions too although not so apparent now. For example ND
over tunnel interfaces, etc.
For below items: (1) yes, IID as ll addresses may break legacy systems
but then one could define new option Target 'Virtual' ll address so
legacy will ignore them, (2) yes ND exchanging IIDs is redundant with
ppp doing same, but then ND doesn't use ppp's IIDs in the NC either, (3)
on system I work on ppp links never exchange NS/NA, (4) 'Virtual' Link
Layer header is like 'Cooked' header in Ethereal captures over tunnel
ifaces, (5) yes ND is about NUD too and finally (6) yes implementations
should follow current RFCs and no incompatible extensions should be
advanced.
Thanks,
Alex
James Carlson wrote:
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.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
