Subject: Progressing draft-ietf-ipv6-over-ppp-v2

From: Brian Haberman <[email-masked]>
Date: Mon, 18 Dec 2006 09:36:58 -0500

IPv6 WG,
      One of the issues raised during IESG review of 
draft-ietf-ipv6-over-ppp-v2 was the lack of clarity in the 
implementation reports on the support of compression, which is required 
in order to move the specification to DS.  Calls went out within the PPP 
and compression communities for additional reports detailing the 
interoperability of this portion of the spec.  Those calls were unanswered.

      Rather than re-cycle the entire spec at PS, Jari has asked that 
the specification be split.  The compression option will move to a new 
draft targeted as a Proposed Standard.  The remaining components will be 
progressed to Draft Standard.  The current draft editor, Srihari Varada, 
has agreed to edit both documents.

      Comments, questions, or concerns?

Regards,
Brian

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

---

From: Eliot Lear <[email-masked]>
Date: Mon, 18 Dec 2006 16:48:54 +0100

>      Comments, questions, or concerns?

Sure.  I've got one.  What conclusion are we to draw from this lack of 
implementation reports on compression?  Is it really the case that 
people are implementing IPv6 over PPP without compression, or is it that 
they are compressing at another layer or what?

Eliot

---

From: James Carlson <[email-masked]>
Date: Mon, 18 Dec 2006 11:00:56 -0500

>       Comments, questions, or concerns?

Given the lack of expressed consensus, that sounds like the right
solution to me.  The document is good enough without it.

-- 
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: Mon, 18 Dec 2006 22:02:53 +0100

Brian Haberman wrote:
> IPv6 WG, One of the issues raised during IESG review of 
> implementation reports on the support of compression, which is
> required in order to move the specification to DS.  Calls went out
> within the PPP and compression communities for additional reports
> detailing the interoperability of this portion of the spec.  Those
> calls were unanswered.
> 
> Rather than re-cycle the entire spec at PS, Jari has asked that the 
> specification be split.  The compression option will move to a new
> draft targeted as a Proposed Standard.  The remaining components will
> be progressed to Draft Standard.  The current draft editor, Srihari
> Varada, has agreed to edit both documents.
> 

Thanks for asking.  I have just discovered this document exists, and I'm
happy with it.

I have several comments, but they're not to slow the progress.  If too
complex to address I can raise them after DS.

Thanks,

Alex

While the document does talk about stateless address autoconf I think it
should also talk about ND.  I think it should mention whether - or not -
it's possible, feasible, has been done or probable, to run IPv6 ND over
a ppp link.  If yes, then the SLLAO/TLLAO options (source link-layer
address option, and target) could be  encoded from the Interface IDs
derived by IPv6CP.  And if we talk link-local IPv6 multicast addresses
on the ppp links then also we can have a meaningful way to describe them.

> As long as the Interface-Identifier is negotiated in the IPV6CP phase
> of the PPP connection setup, it is redundant to perform duplicate
> address detection (DAD) as a part of the IPv6 Stateless Address
> Autoconfiguration protocol [3] on the IPv6 link-local address
> generated by the PPP peer.  It MAY also be redundant to perform DAD
> on any global unicast addresses configured (using an 
> Interface-Identifier that is either negotiated during IPV6CP or 
> generated, for instance, as per [9]) for the interface as part of the
> IPv6 Stateless Address Autoconfiguration protocol [3] provided that
> the following two conditions are met:
> 
> 1) The prefixes advertised, through the Router Advertisement 
> messages, by the access router terminating the PPP link are exclusive
> to the PPP link.
> 
> 2) The access router terminating the PPP link does not autoconfigure
> any IPv6 global unicast addresses from the prefixes that it
> advertises.

Not sure I understand the 2nd condition here.  Is it that we don't want
  the AR to _statelessly autoconfigure_ (a router never does anyways) or
that we don't want the AR to have an address in same prefix as the host?
  How would absence of global address on AR help avoiding DAD?

I also think since ppp is used to connect to an Access Router that that
AR should be a default router, i.e. we can state it in terms of ND RA
lifetimes.

Still in the section stateless autoconfig, it would be worth mentioning
whether the initial RA is sent to all-nodes link-local address, or to
the link-local address that the PPP server delivered to the host.

Finally, there are ppp implementations that don't negotiate the IID with
the server (non compliant with this spec) but who'll still print a
link-local IPv6 address, fe80::something.  That "something" is always
the same, on all hosts here or in Australia, and it's not 0.  It allows
the IPv6 stack so still somehow work even if the PPP peer is not IPv6
capable and if this spec isn't used.  If you think it's worth talking
about this non-compliant IPv6 ppp interface then I could dig the form of
that 'something'.

Thanks for the draft.

Alex

---

From: Brian Haberman <[email-masked]>
Date: Mon, 18 Dec 2006 11:11:29 -0500

> they are compressing at another layer or what?

The only conclusion that I can draw is that no one is willing to perform 
the necessary interoperability tests and provide a public interop report.

Regards,
Brian

---

From: James Carlson <[email-masked]>
Date: Tue, 19 Dec 2006 08:54:40 -0500

Alexandru Petrescu writes:
> a ppp link.

It's being done today.  RFC 2461 specifies that ND is supposed to be
run on point-to-point links.

>  If yes, then the SLLAO/TLLAO options (source link-layer

PPP links don't have layer two addresses; they're point-to-point.

I don't think I agree that these options ought to be used to convey
the PPP Interface ID values.  RFC 2461 says this:

      Source link-layer address
                     The link-layer address of the sender, if known.
                     MUST NOT be included if the Source Address is the
                     unspecified address.  Otherwise it SHOULD be
                     included on link layers that have addresses.

Note that it says "link layers that have addresses."  Point to point
interfaces don't have addresses, and thus ND messages on PPP links
shouldn't include the SLLA/TLLA options.

>   How would absence of global address on AR help avoiding DAD?

In that case, there'd just be one address on the link for the given
prefix.  If there's only one address, you can't possibly have a
conflict.

> AR should be a default router, i.e. we can state it in terms of ND RA

?

A PPP link may or may not represent a link to a router with sufficient
connectivity to be a useful "default router."  The only way you know
is if that router tells you so.

> the link-local address that the PPP server delivered to the host.

I believe that you can do either, and that both should (must) work.

For what it's worth, PPP isn't client-server -- it's peer-to-peer.
One end of the link isn't necessarily privileged in any manner, though
in some particular usages (deployments) this is so.

> about this non-compliant IPv6 ppp interface then I could dig the form of

In my opinion, this is actually compliant with RFC 2472 and with the
update.  If you can't come up with a unique interface identifier,
you're permitted to use another source, such as static configuration:

        Default 
    
          If no valid interface identifier can be successfully 
          negotiated, no default Interface-Identifier value should be 
          assumed. The procedures for recovering from such a case are 
          unspecified.  One approach is to manually configure the 
          interface identifier of the interface. 

It probably _shouldn't_ do that, and yelling at the vendor might help,
but I don't think it's inherently wrong.  (I don't see how it helps at
all if the peer doesn't know IPv6 -- there's no way a non-IPv6-capable
IP node can forward IPv6 datagrams, is there?)

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 19 Dec 2006 18:33:04 +0100

James Carlson wrote:
>> While the document does talk about stateless address autoconf I 
>> think it should also talk about ND.  I think it should mention 
>> whether - or not - it's possible, feasible, has been done or 
>> probable, to run IPv6 ND over a ppp link.
> 

Yes, it does.  But not clear whether peer sends NS to the other peer or
not; or whether peer sends NA or not.  Why would it if there's no
link-layer address.

Not clear what a NC entry looks like when there's no link-layer address.

Not sure what a link-local multicast address looks like over a
point-to-point link: still ff02::1 and ff02::2 (link local)?  Or ff01::1
and ff01::2 (interface local - since both interfaces are tightly connected)?

Not sure the solicited-node address (FF02:0:0:0:0:1:FFXX:XXXX) does
still use the last 24 bits of the Interface ID derived by IPv6CP.

Not sure whether an anycast IID can or shouldn't be negotiated by
IPv6CP.  If the peer is a router it must use a subnet-router 64-0bits
anycast ID on an interface (rfc4291), but ConfigReq with a 0 InterfaceID
is sign of negotiation initiation, not conclusion.

Not sure about an 'anycast ID' rfc2526, which is on 7bits and is part of
the IID, and is same on both peers.  That RFC also says no IID should
ever contain the first 54bits all-ones, so IPv6CP negotation should at
least ensure it never negotiates IIDs whose leftmost 54bits are all ones.

Maybe all of these are out of scope when ND runs over a point to point link?

>> If yes, then the SLLAO/TLLAO options (source link-layer address 
>> option, and target) could be  encoded from the Interface IDs 
>> derived by IPv6CP.  And if we talk link-local IPv6 multicast 
>> addresses on the ppp links then also we can have a meaningful way 
>> to describe them.
> 

I agree they're point to point.

> Source link-layer address The link-layer address of the sender, if 
> known. MUST NOT be included if the Source Address is the unspecified
>  address.  Otherwise it SHOULD be included on link layers that have 
> addresses.
> 

Sounds logic.

To me STLLAOptions carried in ND messages is a good means to have easy
ND when there's no link-layer header to carry link-layer addresses.

>>> 2) The access router terminating the PPP link does not 
>>> autoconfigure any IPv6 global unicast addresses from the prefixes
>>>  that it advertises.
>> Not sure I understand the 2nd condition here.  Is it that we don't
>>  want the AR to _statelessly autoconfigure_ (a router never does 
>> anyways) or that we don't want the AR to have an address in same 
>> prefix as the host? How would absence of global address on AR help
>>  avoiding DAD?
> 

So one would have to prohibit the manual ('administrative') assignment
of that address on the interface too, not just the 'autoconfiguration'
assignment of that address.  A router doesn't autoconfigure an address
based on the RA it sends, neither based on an RA it receives.

Also, a router must assign a subnet-router anycast address (rfc4291) on
the routing interface, that is a prefix::0/128 address; so at least that
address must be assigned on the interface.

Or maybe I don't understand 'autoconfigure' as you do.

>> I also think since ppp is used to connect to an Access Router that
>>  that AR should be a default router, i.e. we can state it in terms
>>  of ND RA lifetimes.
> 
> ?
> 
> A PPP link may or may not represent a link to a router with 
> sufficient connectivity to be a useful "default router."  The only 
> way you know is if that router tells you so.

Ok.

We don't want both of them to be routers and advertise themselves as
default routers either.

>> Still in the section stateless autoconfig, it would be worth 
>> mentioning whether the initial RA is sent to all-nodes link-local 
>> address, or to the link-local address that the PPP server delivered
>>  to the host.
> 
> One end of the link isn't necessarily privileged in any manner, 
> though in sostme particular usages (deployments) this is so.

Yes, I agree - a subsequent reading of the draft reads that the
negotiation reads indeed peer to peer behaviour.

Alex

---

From: James Carlson <[email-masked]>
Date: Tue, 19 Dec 2006 14:17:02 -0500

> not; or whether peer sends NA or not.  Why would it if there's no

I can think of at least one reason: it allows you to minimize the
differences between the operation on point-to-point links and on other
types of links.

For instance, you can still do all the odd things you'd ordinarily do
with the 'R' bit in the NA.

> Not clear what a NC entry looks like when there's no link-layer address.

It has no link-layer address.

> point-to-point link: still ff02::1 and ff02::2 (link local)?

Sure.

>  Or ff01::1

No.  ff01 means same node in IPv6ish.

> still use the last 24 bits of the Interface ID derived by IPv6CP.

Why would it not?  I don't understand why we would want to invent
special cases where none need exist.

> is sign of negotiation initiation, not conclusion.

I don't see what that has to do with IPV6CP.

I assume you're talking about RFC 4291 section 2.6.1.  That address is
constructed in exactly the same manner if PPP links are in use, and
has nothing whatsoever to do with the IPV6CP Interface ID option.  The
PPP negotiation is used for the IPv6 link-local address construction.

You don't (and should _not_) be trying to negotiate those bits used in
the construction of that anycast ID.

> least ensure it never negotiates IIDs whose leftmost 54bits are all ones.

That seems likely to me; I think the authors of RFC 2526 ought to take
this one up, as it's a result of the way this document carves out
space for these special addresses.

> Maybe all of these are out of scope when ND runs over a point to point link?

No ... but I'm not sure that all of these issues are relevant to the
IPV6CP draft.

> ND when there's no link-layer header to carry link-layer addresses.

That sounds like a proposed revision of 2461.  I'm not sure why it's
needed, but I'm pretty sure it's out of scope for IPV6CP.

> based on the RA it sends, neither based on an RA it receives.

Yes.

> address must be assigned on the interface.

Yes, but because it uses all-zeros, it can't possibly conflict with
any IPV6CP interface identifier.

> We don't want both of them to be routers and advertise themselves as

I don't see how we can dictate that people deploy their networks
sanely.  The protocols must work even if the people are silly.

In the case that both are routers, they'll both process the RAs
according to the existing RFCs.  This means that neither will treat
the other as a default, no matter _what_ the RA says.  Presumably, if
they're both routers, then both are running _real_ routing protocols
(such as OSPF) rather than ersatz ones like Router Discovery.

If neither is a router, then you just have a plain old IPv6 link
between two nodes.

I don't see a conflict here.

---

From: <[email-masked]>
Date: Thu, 21 Dec 2006 11:15:32 +0200

Hi,

In my opinion the proposed split is a good way to go forward.

Best regards,

 Teemu 

>-----Original Message-----
>From: ext Brian Haberman [mailto:[email-masked]] 
>Sent: 18 December, 2006 16:37
>To: [email-masked]
>Cc: [email-masked]; Hinden Bob (Nokia-ES/MtView)
>Subject: Progressing draft-ietf-ipv6-over-ppp-v2
>
>IPv6 WG,
>required in order to move the specification to DS.  Calls went 
>out within the PPP and compression communities for additional 
>reports detailing the interoperability of this portion of the 
>spec.  Those calls were unanswered.
>
>      Rather than re-cycle the entire spec at PS, Jari has 
>asked that the specification be split.  The compression option 
>will move to a new draft targeted as a Proposed Standard.  The 
>remaining components will be progressed to Draft Standard.  
>The current draft editor, Srihari Varada, has agreed to edit 
>both documents.
>