Subject: RE: point-to-point links and ND (was: Review of draft-ietf-ipv6-2461bis-09.txt)

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 4 Jan 2007 18:39:15 +1100

> 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-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 04 Jan 2007 19:53:01 +0100

Hesham Soliman wrote:
>> different topic.  I do not give an oppinion in this message about 
>> the original message's comments.
>> 
> => 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

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.

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

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

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

---

From: James Carlson <[email-masked]>
Date: Thu, 4 Jan 2007 15:16:43 -0500

> (multicast, DAD, etc) would run unmodified.

I'm very much opposed to this idea.  Those Interface IDs are not link
layer addresses.  ND options including link layer addresses should be
added _only_ when link layer addresses exist on the underlying media
-- and they don't exist for point-to-point links.

I fear changing this behavior to include Interface IDs instead of link
layer addresses will confuse and break existing implementations.

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

-- 
James Carlson, KISS Network                    <[email-masked]>
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

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 11 Jan 2007 11:27:33 +0100

James Carlson wrote:
>>>> 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.
> 
>  layer addresses.  ND options including link layer addresses should 
> be added _only_ when link layer addresses exist on the underlying 
> media -- and they don't exist for point-to-point links.
> 
> I fear changing this behavior to include Interface IDs instead of 
> link layer addresses will confuse and break existing implementations.
> 
> 
Let's see... not that I've tried it.

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.

If same ppp peer declares that ppp0 interface nd-capable (instead of
currently declared nd-non-capable), and builds a virtual ll header
structure whose format is (src, dst on 64bits) 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?

> Disagree.  Why does it need _any_ link layer address?  Why should it 

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).  At which point it would be difficult to say that ND runs
over ll-less addresses ok.  I think.

Alex

---

From: James Carlson <[email-masked]>
Date: Thu, 11 Jan 2007 09:44:16 -0500

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

> 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

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.

> 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

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-masked]>
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

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 11 Jan 2007 17:27:42 +0100

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:
>> 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.
> 
> 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.
> 
> (unsuccessfully) to send to a link-layer address that doesn't exist.
> 
> 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.
> 
> 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),
> 
>> and builds a virtual ll header structure whose format is (src, dst
>>  on 64bits)
> 
>> 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?
> 
>>> 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).
> 
>> 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 
>  links, but I don't think that implies that it should now be changed
>  in an incompatible manner.
>