> 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.
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. As far as ND is concerned point to point links have a narrow meaning
(mainly related to multicast support). 

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. 

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

Does this mean that a packet sent to a 
 > link-local
 > multicast address sent by one end should be received by the 
 > other w/ or
 > w/o doing MLD  JOIN.  

=> Please see above.

   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. 


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

   For example, is it mandatory to
 > _not_ use S/TLLAOs if there's no link-layer header, or should they be
 > used instead.
 > 
 > 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. 

   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. 

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

Hesham



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

Reply via email to