Hesham Soliman wrote:
Hi Hesham, please allow me to interfere, splitting the thread to a
different topic. I do not give an oppinion in this message about
the original message's comments.
Do you or co-authors think it may be useful to add several
clarifications in the 2461bis with respect to how ND would run on
point-to-point links?
=> I don't think this spec is the right place for it. Let me give
some context to the discussion. The term p-to-p links is actually a
larger umbrella than its common use seems to imply. Under this
umbrella you'll find many cellular *systems* that emulate their
systems as point to point links.
Emulate as ptp links? Sounds strange. I thought they'd emulate shared
links over ptp. What are these systems you mention? I think you may be
wrong cell-system ptp links are emulated. Emulation of what on top of what.
I think maybe you don't talk about emulation but about real ppp
interfaces provided by a wide range of cell-systems.
The requirements vary significantly. And unfortunately, due to the
lack of good definitions and common language we will find that a lot
of people will have their own requirements (initiated by their
systems) for point to point links.
It still holds that ppp protocol runs over a very wide range of such
cellular point to point links, regardless of the system builders
requirements.
As far as ND is concerned point to point links have a narrow meaning
(mainly related to multicast support).
Well, ND to run over ppp links means ND to run on much more than just
cell-systems. All these are concerned by ND clarifications.
BTW, this topic was supposed to be included to the charter according
to the meeting in San Francisco a few years ago but I don't know
what happened to it.
I was not aware of that. I'm not after a new Charter item, just
document clarification for pursuing along the Standards Track.
For example, the draft says multicast 'can' be trivially provided
on point to point links, and interfaces 'can' be assigned
link-local addresses. But does this mean that a host should do a
MLD JOIN on a point to point link.
=> The spec says that nothing needs to be done for those links, so
yes do an MLD join, what's wrong with that? It may be inefficient,
but it doesn't break anything in the spec AFAIK.
That reads like a suggestion for a 'MAY', to which I somehow agree.
In a certain context, widespread IP implementations qualify a p2p link
as non-ND capable, while by your interpretation the spec says nothing
should be done about those links - if so just remove all the p2p
language from ND text.
Does this mean the node should join the solicited-node multicast
address (derived from its IID) when over a point-to-point link?
=> Why not? That's the default operation in the spec and it clearly
states that nothing needs to be done differently for those links.
Well that's a hidden statement; it should better say "do MLD on p2p
links". Or say "don't do MLD on p2p links", or MAY or so.
Implementations don't.
Another aspect is the use of S/TLLAOs on links with no link-layer
headers, typically point to point.
=> No link layer header? I guess you mean no link layer addresses.
I meant both. On most ptp links the IP stack doesn't build a link-layer
header and there are no link-layer addresses; on some IEEE ptp links
there's an id identifying the pair of two ends.
For example this text: Target link-layer address The link-layer
address for the target, i.e., the sender of the advertisement.
This option MUST be included on link layers that have addresses
when responding to multicast solicitations. When responding to a
unicast Neighbor Solicitation this option SHOULD be included.
First, should a NS over point to point link be unicasted or
multicasted, in terms of its dst address. Second, it says this
option MUST be included when link-layer has addresses. It doesn't
say it shouldn't be included if the link-layer doesn't have
addresses.
=> I think that's pretty obvious from the condition in the text. The
inclusion is bound to the existence of an address.
It says it "SHOULD" include a TLLAO in the NA for a received unicasted
NS. It doesn't condition that "SHOULD" on the existence of link-layer
addresses. The condition is on the "MUST" and on the NA multicasted.
Some implementation doesn't send NS to multicast addresses on the ptp
link. So the implementer is left with the text that doesn't have that
condition.
I agree it may be a generic problem with long "MUST" phrases, but it's
obviously a clarification needed (IMHO).
I think it should either say that or its contrary, but not be
silent on this.
=> It's not silent IMO, it does say it.
read again:
This option [TLLAO] MUST be included on link layers that have
addresses when responding to multicast solicitations.
Is there a non-written "and" between "have addresses" and "when
responding to multicast"? Or an "or"? How do you like to read it?
Finally, link-layer addresses have a tight relationship with what
goes in the last 64bits of an address. On ppp (and maybe others?)
links there's no link-layer address but there's means to have
something go into the last 64bits. So could we consider that IID
to be a link-layer address.
=> No we can't, the IID is in a completely different layer. The fact
that you can use an L2 address to generate the IID, does not mean
you can use the IID as an L2 address.
Ok, I tend to think the same, too. But ppp gives an Interface ID and
there's no other means in ppp to have an endpoint identifier. So the
easiest way for ND to run over ppp would be to build some virtual
link-layer headers with Interface IDs in it. All other ND mechanisms
(multicast, DAD, etc) would run unmodified.
We build virtual headers for csum and other AHish stuff, so why not for
ND on ptp links.
Widespread packet capture software builds 'cooked' headers too.
An "Interface ID" is exactly what ND needs on a ppp link.
Alex
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
