Subject: Neighbor Discovery and PPP links

From: Dave Thaler <[email-masked]>
Date: Tue, 17 Jul 2007 09:59:53 -0700

Came across this thread...

http://www1.ietf.org/mail-archive/web/ipv6/current/msg02314.html

However, in looking at draft-ietf-ipv6-over-ppp-v2-03, it seems that
this issue was never addressed.

Is this intentional?  Was there ever an agreement that ND should or
should not be done on PPP links?

(If there was, I haven't found it yet, only uncertainty and the fact
that the IPv6 over PPP RFC has

Interoperability problems and that it should be fixed in
draft-ietf-ipv6-over-ppp-v2.)

-Dave

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

---

From: James Carlson <[email-masked]>
Date: Tue, 17 Jul 2007 13:38:16 -0400

> should not be done on PPP links?

I'm surprised that it's a question at all.  IPV6CP (RFC 2472)
negotiates only interface identifiers, and not addresses, and ND
(2461) says that Neighbor Discovery is supposed to be implemented for
point-to-point links, so I'd expect ND to be used on those links.

Why should the PPP document dictate what IPv6 protocols are needed?

> draft-ietf-ipv6-over-ppp-v2.)

I don't think I agree.  In fact, I don't think the PPP document really
ought to go out of its way to describe how IPv6 works.  That's for the
IPv6 documents to do.

-- 
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: Ole Troan <[email-masked]>
Date: Tue, 17 Jul 2007 18:49:09 +0100

> should not be done on PPP links?

by "ND" you mean address resolution?  I presume there is no disagreement
that other ND functions (DAD,NUD,Router Discovery, Prefix Discovery,
etc) should be done on PPP links.

> draft-ietf-ipv6-over-ppp-v2.)

I don't see the point of doing address resolution on links without
addresses. 2461 seems quite good at specifying that the LLA options
should only be included for links with addresses. what's the possible
interoperabbility issue?

cheers,
Ole

---

From: Dave Thaler <[email-masked]>
Date: Tue, 17 Jul 2007 11:55:18 -0700

I think it's easy to see the disagreement just comparing the responses
from Ole and James.

Ole says: 
> addresses.

James says:
> IPV6CP (RFC 2472) negotiates 
> only interface identifiers, and not addresses, and ND

To answer "what's the possible interoperability issue", Markus Jork
nailed it in the referenced thread:
> If one implementation sends a NS and
> expects to see a NA before sending the first message to the neighbors
> address but the other implementation doesn't use NS/NA messages on the
> PPP link, there is a problem.

We have now observed the problem Markus predicted, with real
implementations.
That is, I know of two non-interoperable implementations of RFC 2472.

I think James' argument does have real substance.  The quote from 2461
section 3.2 is (especially the last sentence):

>     point-to-point - Neighbor Discovery handles such links just like
>                      multicast links.  (Multicast can be trivially
>                      provided on point to point links, and interfaces
>                      can be assigned link-local addresses.)  Neighbor
>                      Discovery should be implemented as described in
>                      this document.

If this is the behavior we agree on, then I think that answers my
question.

-Dave

> -----Original Message-----
> From: Ole Troan [mailto:[email-masked]]
> Sent: Tuesday, July 17, 2007 10:49 AM
> To: Dave Thaler
> Cc: [email-masked]; [email-masked]
> Subject: Re: Neighbor Discovery and PPP links
>

---

From: Ole Troan <[email-masked]>
Date: Tue, 17 Jul 2007 20:11:23 +0100

>> point-to-point links, so I'd expect ND to be used on those links.

I didn't interpret James's reply to mean that his interpretation was to
do address resolution on a link. James can you clarify.

>> PPP link, there is a problem.

the other peer should consider that as a NUD exchange. NS/NA messages
must be supported on PPP links too, otherwise how can you do NUD.

> implementations.  That is, I know of two non-interoperable
> implementations of RFC 2472.
>

agree on PPP links should be treated as multicast links.  that doesn't
mean you should require address resolution before sending packets.

2461, 7.2.2.  Sending Neighbor Solicitations

   When a node has a unicast packet to send to a neighbor, but does not
   know the neighbor's link-layer address, it performs address
   resolution.

for PPP links we always know the link-layer address.

cheers,
Ole

---

From: Dave Thaler <[email-masked]>
Date: Tue, 17 Jul 2007 12:13:42 -0700

Ole Troan wrote:
[...]
> for PPP links we always know the link-layer address.

Yes I agree.

-Dave

---

From: James Carlson <[email-masked]>
Date: Tue, 17 Jul 2007 15:12:14 -0400

> > I don't see the point of doing address resolution on links without

If you've actually got links with no addresses at all, then I agree.
That seems odd, though, given the usual automatic assignment of at
least link-locals.

> That is, I know of two non-interoperable implementations of RFC 2472.

Sigh.

> If this is the behavior we agree on, then I think that answers my

Changing that 'should' to a 'MUST' may fix the problem with the
document.

As for implementations, I'd expect the implementor to have a really
good explanation of why he ignored fairly clear (if not capitalized)
'should' advice like that, if it was in fact done on purpose.  If it's
just a bug, then it's a bug, and might not need to be immortalized.

My reading of that text is that if the peers have prior agreement that
they're not going to do ND, and if the designer or user of the system
has a Very Good Reason to believe that omitting ND is desirable, then
it's possible to do.  Otherwise, as with any recommendation, you
'should' do what it says, and use ND as usual.

I don't know of any cases where omitting ND for IPv6 addresses makes
much sense.

---

From: James Carlson <[email-masked]>
Date: Tue, 17 Jul 2007 15:29:15 -0400

> do address resolution on a link. James can you clarify.

Yes, I expect address resolution to be done on PPP links, just as is
described in 2461.  I expect it to be done _regardless_ of the
underlying link technology.

> must be supported on PPP links too, otherwise how can you do NUD.

Indeed.

> mean you should require address resolution before sending packets.

That text says that "Neighbor Discovery should be implemented as
described in this document."  I don't see how that's unclear, or how
it supports a "may solicit if you feel like it" design.

> for PPP links we always know the link-layer address.

That seems like a too-strict reading of that text.  I think the issue
here is that this explanatory text has too much of an Ethernet bias,
and could be worded better.

I think that this was unintentional, as later on in the same section,
it goes on to say:

   If the solicitation is being sent to a solicited-node multicast
   address, the sender MUST include its link-layer address (if it has
   one) as a Source Link-Layer Address option.  Otherwise, the sender

In what cases don't you have a link layer address, other than point-
to-point?  As long as this is describing what to do with point-to-
point, why read the introduction as ruling out the use of
solicitations on PPP links?

Instead, the issue is that if the neighbor cache entry doesn't exist
or is STALE, then you need to solicit.  It's not a matter of just
"knowing" (somehow) that the peer doesn't have any link-layer address.

Plus, as you point out, unreachability detection falls apart if ND
isn't there.  And you don't get to see the weird 'R' bit.

---

From: Markku Savela <[email-masked]>
Date: Tue, 17 Jul 2007 22:57:11 +0300

> underlying link technology.

If link like PPP does not have link layer addresses, there is no point
in doing "address resolution". Nobody should require implemenatation
to do pointless silly things. I believe trying to put SLA option on
NS/NA on a link without link layer addresses is actually violation of
RFC and causes the messages to be ignored.

If link like PPP does have link layer addresses, normal ND rules fully
apply.

However, DAD is perfectly sensible. And, any other ND messages that
make sense without SLA are perfectly ok and usable.

---

From: James Carlson <[email-masked]>
Date: Tue, 17 Jul 2007 16:09:46 -0400

> RFC and causes the messages to be ignored.

I wasn't suggesting using the SLLA option.  It wouldn't make sense.
In fact, the RFC says that you don't include that option if you don't
have a link-layer address.

What I was suggesting was that you still need to perform neighbor
discovery per 2461, even though the peers on a point-to-point link
don't have any link layer addresses.

> If link like PPP does have link layer addresses, normal ND rules fully

What PPP creates is explicitly a point-to-point link, not point-to-
multipoint or some other case.  I'm not sure I understand the
statement you're making here, as it seems to suggest a situation that
doesn't exist.

> make sense without SLA are perfectly ok and usable.

Sure.

What messages, though, _don't_ make sense without SLLA or TLLA
options?  I think all of them are defined to work that way.  Am I
missing something?

---

From: Ole Troan <[email-masked]>
Date: Tue, 17 Jul 2007 21:21:30 +0100

> That seems odd, though, given the usual automatic assignment of at

sorry, I meant links without link-layer addressing.

>> I think James' argument does have real substance.  The quote from
>> 2461 section 3.2 is (especially the last sentence):
>> 

OK, so at least we've clarified that we're in disagreement. I don't see
support in the specs for doing address resolution on links without
link-layer addresses. what would the purpose be in doing address
resolution on a link without link-layer addresses?

other ND functions, of course they should be supported.

cheers,
Ole

---

From: James Carlson <[email-masked]>
Date: Tue, 17 Jul 2007 16:35:33 -0400

> resolution on a link without link-layer addresses?

Generating NS and processing NA drives the state machine associated
with neighbor cache entries.

> other ND functions, of course they should be supported.

I don't see how you get there at all.  You need to be doing
solicitations and advertisements in order to do unreachability
detection and those "other ND functions," don't you?

If you're going to somehow omit ND for address resolution, but use it
for everything else, what exactly does that look like on the wire, and
what support in the existing RFC is there for this sort of operation?

I know what the current RFC suggests -- that is, that we send all of
the usual messages based on neighbor cache entry state (just as with
broadcast-type networks), but that the SLLA/TLLA option isn't used on
any messages because the peers are point-to-point.  It's the same
protocol -- one option less.

What alternative usage are you suggesting?  At a guess, the system
that would send NS because it lacks a neighbor cache entry instead
simply creates the entry and "jumps" straight to REACHABLE state
because it already "knows" where the peer is located.  Is that it?
What other protocol changes are required in order to make ND-for-
everything-but-address-resolution mode work?

---

From: Ole Troan <[email-masked]>
Date: Tue, 17 Jul 2007 23:22:09 +0100

> detection and those "other ND functions," don't you?

sure, if you need those functions.  on router to router links you don't
need NUD, which is why I don't want to make it a MUST in the
specification. 

> everything-but-address-resolution mode work?

no, if you need reachability confirmation you need to go through the
whole shebang.

cheers,
Ole

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 18 Jul 2007 13:55:38 +0900

At Tue, 17 Jul 2007 16:35:33 -0400,

> what support in the existing RFC is there for this sort of operation?

What the BSD (KAME) implementation does is as follows:

- when it first sends a packet to the other end of a point-to-point
  (including PPP) link it creates a placeholder of a neighbor cache
  with the state of STALE
- the packet is sent to the p2p link immediately since there is no
  need to perform address resolution
- eventually the state of the neighbor cache entry is changed to PROBE
  and NUD is performed
(this description is a bit simplified to concentrate on the main point
of this discussion)

I believe this is a reasonable behavior, although as far as I know the
protocol specification does not specify this level of details
(e.g. what should be the initial state of such a cache entry).

In any case, it's totally pointless for an implementation to hold the
packet during an exchange of NS/NA for address resolution (which
itself is meaningless) on such a link.  Furthermore, if the
implementation doesn't send the held packet unless it gets an NA in
response to NS, it may cause an interoperability problem depending on
the behavior of the other end.  I guess that's the issue Dave
originally tried to indicate.  I don't know of an implementation that
performs the meaningless NS/NA for address resolution on a p2p link,
but I know an implementation that doesn't respond to an NS (whether
it's for address resolution or for NUD) on a p2p link, so I won't be
surprised if the problem actually happens.

As far as I can see the current specification is pretty clear to
prevent such a pointless behavior, but if there is an implementation
that behaves that way (Dave's message seems to indicate there is) it
may make sense to write a short I-D that clarifies this point.  In
this case I believe it should be a generic note on point-to-point link
that doesn't have the notion of L2 address (and thus doesn't require
L2 address resolution) rather than a part of a document for a specific
link type such as ipv6-over-ppp-v2.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 18 Jul 2007 12:21:43 -0400

Ole and Dave agreed upon: "for PPP links we always know the link-layer
address". I too agree with that. Why issue an NS to resolve an address
on such a link when the address is always known?

As for NUD, 2461 NUD sections also say if upper layer protocols can
determine reachability, NUD is not invoked. Why does PPP need NUD if PPP
control protocol supports keepalive for the data connection - if
keepalive is missed, the PPP connection will be terminated.

The PPP interoperability problem that Dave raised is a general problem
outside of PPP too in that when a host is expected to forward data out
of the host, the host is performing address resolution. The default
router or other directly connected PPP client may not respond to this NS
causing the host to sit waiting for an NA. We have raised such a point
in 2nd paragraph of Introduction section of our I-D.

http://www.ietf.org/internet-drafts/draft-wbeebee-nd-implementation-pitf
alls-01.txt

Personally, I won't use address resolution or NUD in a PPP link. Further
I wouldn't also use DAD in a PPP link because I agree with text in RFC
2472, section 5 that says

"Therefore it is recommended that for PPP links with
   the IPV6CP Interface-Identifier option enabled the default value of
   the DupAddrDetectTransmits autoconfiguration variable [3] be zero."

Further, all of us have agreed that PPP IPV6 ND behavior belongs in an
IPv6 RFC, not a PPP specific RFC. I think RFC 2461bis is clear for PPP
ND behavior. However if folks still feel 2461bis can be clarified for
PPP, we can continue that discussion. Since our I-D is focused on
clarifying 2461bis in the areas of on-link vs. off-link determination,
address resolution vs. forwarding data out, we can add some
clarifications related to PPP in our I-D as well. In -01 version of our
I-D, section 5 "Changes to draft-ietf-ipv6-rfc2461bis-11" is very
sparse. The section is now complete in a -02 version we are working on.

Another gross change we have made in our I-D since the -01 version is
that the -02 version has a new section 7 that is modeled after RFC 2525.
We are collecting IPv6 ND bugs in this section. I think it makes sense
to add the PPP problem Dave raised as a Interoperability bug in section
7 of our I-D. To give you a flavor of what's in -02 version of our I-D,
see the table of contents below.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Host Models  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  RA Sets M and O Bits but does not Include the Prefix
           Information Option (PIO) . . . . . . . . . . . . . . . . .  6
     2.2.  RA Advertises a Prefix with the On-link(L) Bit Set . . . .  6
       2.2.1.  When the Valid Lifetime Expires  . . . . . . . . . . .  8
     2.3.  RA Advertises a Prefix with the On-link(L) Bit Clear . . .  8
   3.  Router Models  . . . . . . . . . . . . . . . . . . . . . . . .  8
     3.1.  Aggregation Router Deployment Model  . . . . . . . . . . .  9
   4.  Redirect Clarifications  . . . . . . . . . . . . . . . . . . .  9
   5.  Changes to draft-ietf-ipv6-rfc2461bis-11 . . . . . . . . . . . 10
   6.  Changes to draft-ietf-ipv6-rfc2462bis-08 . . . . . . . . . . . 14
   7.  Known IPv6 ND Implementation Problems  . . . . . . . . . . . . 15
     7.1.  Incorrect host data forwarding behavior after
           receiving an RA with no PIO  . . . . . . . . . . . . . . . 16
     7.2.  A DHCPv6 host sending 9 NS(DAD)s . . . . . . . . . . . . . 20
     7.3.  Incorrect host behavior after automatic insertion of a
           directly connected route during  address acquisition . . . 22
     7.4.  Aggregation router sending Redirects when hosts
           communicate to each other from behind  different modems  . 25
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 26
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 27
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 27
     11.2. Informative References . . . . . . . . . . . . . . . . . . 27
   Appendix A.  CHANGE HISTORY  . . . . . . . . . . . . . . . . . . . 28
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
   Intellectual Property and Copyright Statements . . . . . . . . . . 30

Regards,

Hemant

-----Original Message-----
From: JINMEI Tatuya / ???? [mailto:[email-masked]] 
Sent: Wednesday, July 18, 2007 12:56 AM
To: James Carlson
Cc: Dave Thaler; [email-masked]; [email-masked]
Subject: Re: Neighbor Discovery and PPP links

I believe this is a reasonable behavior, although as far as I know the
protocol specification does not specify this level of details (e.g. what
should be the initial state of such a cache entry).

In any case, it's totally pointless for an implementation to hold the
packet during an exchange of NS/NA for address resolution (which itself
is meaningless) on such a link.  Furthermore, if the implementation
doesn't send the held packet unless it gets an NA in response to NS, it
may cause an interoperability problem depending on the behavior of the
other end.  I guess that's the issue Dave originally tried to indicate.
I don't know of an implementation that performs the meaningless NS/NA
for address resolution on a p2p link, but I know an implementation that
doesn't respond to an NS (whether it's for address resolution or for
NUD) on a p2p link, so I won't be surprised if the problem actually
happens.

As far as I can see the current specification is pretty clear to prevent
such a pointless behavior, but if there is an implementation that
behaves that way (Dave's message seems to indicate there is) it may make
sense to write a short I-D that clarifies this point.  In this case I
believe it should be a generic note on point-to-point link that doesn't
have the notion of L2 address (and thus doesn't require
L2 address resolution) rather than a part of a document for a specific
link type such as ipv6-over-ppp-v2.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba
Corp.
					[email-masked]

---

From: James Carlson <[email-masked]>
Date: Wed, 18 Jul 2007 12:20:25 -0400

>   (including PPP) link it creates a placeholder of a neighbor cache

I understand the desire, but I don't think the current RFC supports
that behavior.  Section 5.2 sets out the basic operation:

   Once the IP address of the next-hop node is known, the sender
   examines the Neighbor Cache for link-layer information about that
   neighbor.  If no entry exists, the sender creates one, sets its state
   to INCOMPLETE, initiates Address Resolution, and then queues the data
   packet pending completion of address resolution.  For multicast-
   capable interfaces Address Resolution consists of sending a Neighbor
   Solicitation message and waiting for a Neighbor Advertisement.  When

And, as documented in 2.2, point-to-point links (such as PPP) are
assumed to be multicast-capable:

   point-to-point - a link that connects exactly two interfaces.  A
                    point-to-point link is assumed to have multicast
                    capability and have a link-local address.

The implication is that a trip through INCOMPLETE isn't optional.  I
agree that it (at least in theory) could be, but I don't see how the
existing text supports what you're describing.

Sure.

> (e.g. what should be the initial state of such a cache entry).

Actually, it does.  Section 7.2.2 specifies that new entries are
created in INCOMPLETE state.

It might be possible to carve out an exception for point-to-point, but
I don't see one there now.  I *think* that you're hanging your
argument on this phrase from section 7.2.2:

I believe that this needs to be cleared up.  If it really means that
point-to-point links should not send NS and wait for NA, then it
should say so and it should not go on to explain what
"multicast-capable" interfaces (which include point-to-point) links
should do.

> itself is meaningless) on such a link.  Furthermore, if the

I agree that it seems pointless, but it's what the current text says.

> surprised if the problem actually happens.

It doesn't respond to a valid NS?  How is that a viable
implementation.

In this part, I think you're just describing a bug.  I don't see
anything in the RFC that supports simply ignoring an NS.  (And if you
do that, then how can NUD possibly work?)

> link type such as ipv6-over-ppp-v2.

The part I support is clarifying the document.  I don't think I
support changing the functionality described in the document.

---

From: James Carlson <[email-masked]>
Date: Wed, 18 Jul 2007 12:44:57 -0400

Hemant Singh (shemant) writes:
> determine reachability, NUD is not invoked.

Right.  However, PPP is a lower-layer protocol.  I don't know why TCP
would be signaling address reachability, but that's what the RFC seems
to allow.  It says nothing about the link-layer itself signaling
reachability.

> Why does PPP need NUD if PPP

PPP has both signals from the physical layer (if present) and an
optional LCP Echo-Request mechanism that can be (and often is) used to
implement a link-layer keepalive.  You're right that NUD shouldn't be
needed, and yet that's just what RFC 2461 says.

> in 2nd paragraph of Introduction section of our I-D.

So, why would a reasonable peer fail to respond to an NS?  Even if you
don't believe that the existing RFC requires the use of ND for
point-to-point links, why would you fail to respond to a solicitation
for your own address?

> http://www.ietf.org/internet-drafts/draft-wbeebee-nd-implementation-pitf

I don't see a reference to point-to-point links there.

>    the DupAddrDetectTransmits autoconfiguration variable [3] be zero."

Note that IPv6 addresses can be configured manually and can
potentially come from other sources that do not guarantee uniqueness.

That doesn't sound like a good recommendation to me.  The whole point
to inventing IPCP (for IPv4) was because we had chaos on SLIP links,
where fumble-fingered users would sometimes set the same address on
both end, with hilarious results.  Why duplicate that history?

(However, I do like the idea of getting rid of that 'R' bit, at least
in some cases.  The less it's seen, the better.)

> IPv6 RFC, not a PPP specific RFC.

Strongly agreed.

> I think RFC 2461bis is clear for PPP
> ND behavior.

Apparently, it's not.  I've read it several times, and it still seems
to support the same model as before, which is that NS is required, and
that newly-created neighbor cache entries must go to INCOMPLETE state
and use NS before becoming REACHABLE.  There are no exceptions for
point-to-point links that I can see, and the ones that others seem to
be citing are ambiguous at best.

>            communicate to each other from behind  different modems  . 25

Nine DADs is a problem?  It might be a local problem for the sender
(it'll take a while to get that address ready), but it hardly seems
like a serious implementation issue.

Looking forward to reading that text.  ;-}

---

From: Tim Hartrick <[email-masked]>
Date: Wed, 18 Jul 2007 10:08:54 -0700

All,

> support changing the functionality described in the document.

I agree with this sentiment.  It is reasonable for an implementation of
IPv6 over PPP to restrict what it sends based on the desire to avoid
initiating address resolution, NUD or DAD exchanges.  It isn't
reasonable, and as far I as I can see out of spec, for implementations
to not respond to attempts by their peer to do address resolution, NUD
or DAD exchanges.

tim

---

From: Dave Thaler <[email-masked]>
Date: Wed, 18 Jul 2007 15:54:01 -0700

> keepalive is missed, the PPP connection will be terminated.

Because addresses (e.g. RFC3041 addresses, manually configured
addresses, addresses derived from a prefix which is no longer being
advertised in the RA, etc.) can go away even though the PPP connection
stays up.
 
> alls-01.txt
> 
> Personally, I won't use address resolution or NUD in a PPP link. 

Then you will fail in cases like the one I noted above, and you won't be
RFC compliant.  RFC2461 requires NUD on _all_ links.  (I don't think
anyone is arguing it doesn't.)

> Further

Actually after some more investigation, I think I understand the source
of the interoperability issue.  The core issue is that some PPP servers
actually handle multiple PPP connections to different clients via a
common interface.  Hence from the server's perspective, it's not a
point-to-point link, but rather an NBMA link.  From the client's
perspective, the client thinks it's a point-to-point link, and there's
no way to discover that the server thinks otherwise.

>                    capability and have a link-local address.

However, in the case above, the "link" (being the area bounded by Hop
Limit decrement, which won't happen between two clients since the server
is logically bridging them together without a Hop Limit decrement) does
not contain exactly two interfaces, and hence it doesn't fit the above
definition of point-to-point link.  This means that:

	PPP != point-to-point

(and the terms should not be confused).

If the server believes its many-PPP-client interface is an NBMA link,
then the following quote from RFC2461 applies (especially the last
phrase):

>   non-broadcast multi-access (NBMA)
>                  - a link to which more than two interfaces can
attach,
>                    but that does not support a native form of
multicast
>                    or broadcast (e.g., X.25, ATM, frame relay, etc.).
>                    Note that all link types (including NBMA) are
>                    expected to provide multicast service for IP (e.g.,
>                    using multicast servers), but it is an issue for
>                    further study whether ND should use such facilities
>                    or an alternate mechanism that provides the
>                    equivalent ND services.

Hence one can understand how some implementers could conclude that
normal ND (as opposed to NUD) wouldn't apply.

The core underlying principle is that without explicit knowledge from
some source, one can never conclude that a link that looks like
point-to-point to you, really is.

-Dave

---

From: Ole Troan <[email-masked]>
Date: Thu, 19 Jul 2007 00:15:40 +0100

Dave,

> anyone is arguing it doesn't.)

as long as we also agree that it is perfectly valid to operate p2p links
with NUD turned off.

/ot

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 19 Jul 2007 01:53:27 +0200

> as long as we also agree that it is perfectly valid to operate p2p  

This is a strange discussion.

People have different opinions about what behavior makes sense. I can  
follow the reasoning behind most of them. But the notion that an  
implementation should just do what the implementation thinks is best  
without checking with the other side is BAD. As someone else said, we  
lived through that with SLIP and we fixed it for IPv4 with PPP. The  
PPP way of handling these things is by negotiating during the *CP  
phase, NOT blindly assuming facts not in evidence.

The discussion about whether neighbor discovery is useful is mostly a  
rathole. Neighbor discovery isn't the problem on a true point-to- 
point link. The real question is: what about router advertisements?  
Should they be sent and should they be expected?

But even THAT is not the biggest problem with IPv6 over PPP. Unless  
you're dealing with dial-up, the PPP link will more often than not  
terminate on a (home) router, which means that you not only need a  
subnet for the PPP link delegated by the router at one end of the  
link, but also a prefix that can be used on the LAN behind the router  
that terminates the PPP link on the opposite side.

In my opinion, we should either say that PPP is just another  
multicast-capable link technology which means that we do vanilla ND,  
NUD, DAD, RAs and DHCPv6 prefix delegation, OR we say PPP is a  
special case, throw out all that stuff we use on ethernet and specify  
IP6CP options that implement the functionality that is relevant over  
a point-to-point link under common point-to-point constraints (i.e.,  
low bandwidth, high delay, often operating on battery power).

Mixing the two approaches can only lead to even more interoperability  
problems down the road. In my book I tell people to forget about IPv6  
over PPP because it's pretty much impossible to make it do something  
useful in the real world. It would be great if I could remove that  
little piece of advice in a future edition.

---

From: Dave Thaler <[email-masked]>
Date: Wed, 18 Jul 2007 16:59:59 -0700

> Sent: Wednesday, July 18, 2007 4:16 PM
> To: Dave Thaler
> Cc: Hemant Singh (shemant); JINMEI Tatuya / ????; James Carlson;
> [email-masked]; [email-masked]

Yes (but only for router-to-router connections which I believe is what
you're referring to).  

RFC 2461 states:
> Neighbor Unreachability Detection is used for all paths between hosts
> and neighboring nodes, including host-to-host, host-to-router, and
> router-to-host communication.  Neighbor Unreachability Detection may
> also be used between routers, but is not required if an equivalent
> mechanism is available, for example, as part of the routing
> protocols.

-Dave

---

From: Ole Troan <[email-masked]>
Date: Thu, 19 Jul 2007 01:14:16 +0100

> Yes (but only for router-to-router connections which I believe is what

indeed. (our implementation doesn't do NUD on router to host p2p links
either, but it obviously replies to NUD being initiated from the other
peer in both cases.). NUD is a bad idea for router to host anyway, but
don't get me started on that.

cheers,
Ole

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 19 Jul 2007 11:53:18 -0400

Dave,

I read thru all the emails between you and Ole. I agree with Ole that
router-to-host NUD is a bad idea on p2p links. Please see in line below
with "<hs>". 

-----Original Message-----
From: Dave Thaler [mailto:[email-masked]] 
Sent: Wednesday, July 18, 2007 6:54 PM
To: Hemant Singh (shemant); JINMEI Tatuya / ????; James Carlson
Cc: [email-masked]; [email-masked]
Subject: RE: Neighbor Discovery and PPP links

<hs> Not quite. If the network layer in PPP link has to send packets,
then a new NCP session has to be established and IPV6CP (as defined in
RFC 2472 to be NCP protocol for PPP over IPv6) will negotiate the new
addresses of both ends. I expect that even when an IPv6 PPP end point is
manually configured, there are means available on the client to enforce
a new IPV6CP session. Once the new address is negotiated by IPV6CP, PPP
keepalive will maintain reachability. Am I missing anything here?

<hs> No. See my response above. On a related note, as you and Ole have
agreed upon, a PPP link always knows the link-layer address, so this PPP
interoperability problem you reported can be fixed if the PPP client
never issues an NS for address resolution - this is a mcast NS, not a
unicast NS that is sent by NUD.

<hs> If the PPP client-server scenario falls under an NBMA link, then as
you have shown text below, it is an area of further study. We seem to be
doing a bit of further study in this thread.

	PPP != point-to-point

attach,
multicast

<hs> Right. But that is why I like the IPv6 ND models where one has an
explicit flag for "Is router" or not - such a model takes care of Hop
Limit decrement and also knows what sources are is terms of host or
router. I am not sure what the PPP deployment model is in terms or
routers besides such servers to reply. I need to see a complete
deployment picture.
 
Thanks.

Hemant

-Dave

---

From: Dave Thaler <[email-masked]>
Date: Thu, 19 Jul 2007 12:58:39 -0700

Hemant Singh writes:
> Hemant Singh writes:
> > [...] Why does PPP need NUD if PPP

Yes, you don't need IPv6CP to add addresses.  IPv6CP negotiates an
interface identifier that can be used with stateless addrconf.  The
client can construct as many other interface identifiers as it wants
(e.g. for RFC3041 addresses) and need not use IPv6CP for them, but it
does have to do DAD for them.

[...]
> unicast NS that is sent by NUD.

I'm not talking about mcast NS's in my response you're saying No to.
I'm talking about unicast NUD.  Unicast NS's are used on all links
(except for router-to-router links that you have some other mechanism
for) per RFC2461.

[...] 

-Dave

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 19 Jul 2007 22:20:51 +0200

On 19-jul-2007, at 21:58, Dave Thaler wrote:

> you don't need IPv6CP to add addresses.  IPv6CP negotiates an
> interface identifier that can be used with stateless addrconf.

Apparently I'm missing something too, because I really don't get the  
logic behind this approach. DAD will take care of making sure that  
the interface identifiers don't clash, which is as good as guaranteed  
anyway if at least one end can borrow an EUI-64 from another interface.

In practice I haven't been able to get stateless autoconfig to work  
over PPP, and even if it would work first doing an IP6CP exchange and  
then router solicitation/router advertisement/neighbor discovery is  
suboptimal. Especially since this only covers the case where you need  
a single IPv6 address, a use case that's quickly dying out (i.e.,  
dial-up).

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 19 Jul 2007 16:22:57 -0400

Please see in line below against "<hs>". 

-----Original Message-----
From: Dave Thaler [mailto:[email-masked]] 
Sent: Thursday, July 19, 2007 3:59 PM
To: Hemant Singh (shemant); JINMEI Tatuya / ????; James Carlson
Cc: [email-masked]; [email-masked]
Subject: RE: Neighbor Discovery and PPP links

<hs> Gotcha. I guess when section 5 of RFC 2472 uses the plural
addresses word in text snipped below, the plural is for both ends of the
PPP link and not all unicast IPv6 addresses assigned to the client:

[The Interface Identifier of IPv6 unicast addresses [6] of a PPP
   interface, SHOULD be negotiated in the IPV6CP phase of the PPP
   connection setup (see section 4.1). ]

Certainly if any PPP configured address does not undergo IPV6CP, then
DAD has to be initiated for those addresses. I would like to clarify RFC
2472 to make explicit statements that some unicast addresses of a PPP
client will not undergo IPV6CP and DAD will be used for those addresses.

[...]

<hs> OK. Router-to-router is already a well-known link that NUD can be
skipped for as even 246bis says. Ole does not like router-to-host
unicast NS NUD messages as well. I agree with him. 

Thanks.

Hemant

[...] 

-Dave

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 19 Jul 2007 16:48:01 -0400

Dave,

It also seems awkward to me to use IPV6CP for one unicast address (and
associated interface id) of a PPP client and use DAD for any more
unicast addresses configured for the PPP client. Seems like muddying the
waters to me. Why not use IPV6CP for all addresses? Going along with
what Iljitsch van Beijnum is saying, who is deploying SLAAC with PPP
that we will then have to think about privacy addresses etc? 

Hemant

-----Original Message-----
From: Dave Thaler [mailto:[email-masked]] 
Sent: Thursday, July 19, 2007 3:59 PM
To: Hemant Singh (shemant); JINMEI Tatuya / ????; James Carlson
Cc: [email-masked]; [email-masked]
Subject: RE: Neighbor Discovery and PPP links

[...]

[...] 

-Dave

---

From: Dave Thaler <[email-masked]>
Date: Thu, 19 Jul 2007 13:50:08 -0700

Below.

> From: Hemant Singh (shemant) [mailto:[email-masked]]
> Sent: Thursday, July 19, 2007 1:23 PM
> To: Dave Thaler; JINMEI Tatuya / ????; James Carlson
> > addresses of both ends. I expect that even when an IPv6 PPP end
point
> is

Yep.  RFC 2472 states:
> 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 as a part of the IPv6 Stateless Autoconfiguration
> protocol [3].

The key phrase being "as long as the" (keeping in mind that a host can
use multiple interface identifiers simultaneously, so this is a per
interface identifier statement).  

The problematic statement in 2472 is the one immediately after the above
quote:

>  Therefore it is recommended that for PPP links with
> the DupAddrDetectTransmits autoconfiguration variable [3] be zero.

since the quote above doesn't take into account other interface
identifiers.

2472bis makes it much more clear by adding more text in between the two
statements, such that it restricts the first quote to applying to the
link-local address only, and narrows the second quote to only applying
when two other conditions are met such it doesn't apply to uses of PPP
like the problematic case I described.  (Basically where you have
knowledge that it is indeed a point-to-point not NBMA link, and where
you have knowledge that the router has no global addresses, hence the
change from 2472 is that skipping DAD would never be the default for an
arbitrary PPP link.)

> unicast NS NUD messages as well. I agree with him.

Currently RFC2461 doesn't support that view.  If this is the WG
consensus, then it would be good to put the rationale into a draft that
can update 2461.

-Dave

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 19 Jul 2007 17:10:14 -0400

James,

I am talking off of this statement in RFC 2472, section

Even they talk about a unicast address when they are referring to a
Link-local address and interface-id 

All I am saying is, if IPV6CP is used to negotiate one interface-id,
when multiple addresses, that Dave pointed out, are needed for the same
client, why not use IPV6CP to negotiate interface-id's for even these
addresses?

Hemant

-----Original Message-----
From: James Carlson [mailto:[email-masked]] 
Sent: Thursday, July 19, 2007 4:52 PM
To: Hemant Singh (shemant)
Cc: Dave Thaler; JINMEI Tatuya / ????; [email-masked]; [email-masked]
Subject: RE: Neighbor Discovery and PPP links

> unicast addresses configured for the PPP client. Seems like muddying 
> the waters to me. Why not use IPV6CP for all addresses?

I'm confused.  IPV6CP doesn't negotiate any IPv6 addresses at all.  It
just negotiates the interface token that is used for link-locals and
_may_ be used to construct autoconf addresses.

> Going along with

It works today on Solaris ... not sure about others.

---

From: James Carlson <[email-masked]>
Date: Thu, 19 Jul 2007 16:52:26 -0400

Hemant Singh (shemant) writes:
> waters to me. Why not use IPV6CP for all addresses?

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 19 Jul 2007 17:20:21 -0400

Dave,

Are you suggesting someone puts together a 2472bis or does such an I-D
already exist? I couldn't find it. This issue that you raised yesterday
where you said:

"The core issue is that some PPP servers actually handle multiple PPP
connections to different clients via a common interface.  Hence from the
server's perspective, it's not a point-to-point link, but rather an NBMA
link.  From the client's perspective, the client thinks it's a
point-to-point link, and there's no way to discover that the server
thinks otherwise."

belongs in a PPP document to be discussed. Just like IPv6 ND RFC's
discuss router and host, I think it makes sense for a PPP document to
discuss a server and client because the server is behaving differently
for the PPP link. By all means, if it makes sense to modify anything in
PPP NCP or any other related protocol to incorporate the notion of
server vs. client, be my guest.

As for the view Ole pointed out for dislike of router-to-host NUD,
certainly the rationale for that view makes sense to be brought out, and
changes be added to a draft that will update 2461. Let's see what do
other folks say.

Thanks.

Hemant 

-----Original Message-----
From: Dave Thaler [mailto:[email-masked]] 
Sent: Thursday, July 19, 2007 4:50 PM
To: Hemant Singh (shemant); JINMEI Tatuya / ????; James Carlson
Cc: [email-masked]; [email-masked]
Subject: RE: Neighbor Discovery and PPP links

Below.

> > > [...] Why does PPP need NUD if PPP control protocol supports 
> > > keepalive for the data connection - if keepalive is missed, the 
> > > PPP connection will be terminated.
> >
point

quote:

>  Therefore it is recommended that for PPP links with the IPV6CP 
> Interface-Identifier option enabled the default value of the 
> DupAddrDetectTransmits autoconfiguration variable [3] be zero.

-Dave

---

From: James Carlson <[email-masked]>
Date: Thu, 19 Jul 2007 17:19:48 -0400

> client, why not use IPV6CP to negotiate interface-id's for even these

We'd have to discuss that on the PPP list, but my take on it is that
it'd likely be incompatible with existing implementations.  I don't
know that anyone expects more than one IPV6CP Interface-Identifier
option -- I know for certain that the open source ppp-2.4
implementation wouldn't handle it right.

I think it'd be pretty strange operationally as well.  You'd end up
with multiple link-local addresses.

I don't think I agree with pushing this issue down into PPP.  We don't
do that for Ethernet, so why would PPP be special?

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 19 Jul 2007 17:41:20 -0400

I am certainly not suggesting using more than one Link-Local address for
a PPP client. All I am saying is if PPP uses IPV6CP and interface-id for
Link-Local address, it is a little odd to use DAD for rest of the
addresses assigned to the PPP client - the privacy and other addresses
that Dave alluded to. I don't want to change PPP in such a radical way -
given the nature of the p2p link it's not so odd if Link-local address
is negotiated using IPV6CP and other addresses of the PPP client use
DAD. We should just make such facts clear in 2472bis.

Thanks.

Hemant

-----Original Message-----
From: James Carlson [mailto:[email-masked]] 
Sent: Thursday, July 19, 2007 5:20 PM
To: Hemant Singh (shemant)
Cc: Dave Thaler; JINMEI Tatuya / ????; [email-masked]; [email-masked]
Subject: RE: Neighbor Discovery and PPP links

Hemant Singh (shemant) writes:
> when multiple addresses, that Dave pointed out, are needed for the 
> same client, why not use IPV6CP to negotiate interface-id's for even 
> these addresses?

We'd have to discuss that on the PPP list, but my take on it is that
it'd likely be incompatible with existing implementations.  I don't know
that anyone expects more than one IPV6CP Interface-Identifier option --
I know for certain that the open source ppp-2.4 implementation wouldn't
handle it right.

I think it'd be pretty strange operationally as well.  You'd end up with
multiple link-local addresses.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 19 Jul 2007 17:50:36 -0400

Dave, 

Never mind, I found what's 2462bis. I got hold of

http://www.ietf.org/internet-drafts/draft-ietf-ipv6-over-ppp-v2-03.txt

Thanks to Srihari who sent me an email.

Hemant 

-----Original Message-----
From: Dave Thaler [mailto:[email-masked]] 
Sent: Thursday, July 19, 2007 4:50 PM
To: Hemant Singh (shemant); JINMEI Tatuya / ????; James Carlson
Cc: [email-masked]; [email-masked]
Subject: RE: Neighbor Discovery and PPP links

Below.

point

-Dave

---

From: James Carlson <[email-masked]>
Date: Thu, 19 Jul 2007 17:48:43 -0400

Hemant Singh (shemant) writes:
> that Dave alluded to.

I don't see why it's odd.  Shouldn't we worry about misconfiguration
for those addresses as well?  Wouldn't it be "bad" if there were a
conflict with both peers choosing to use the same non-link-local
address?

> I don't want to change PPP in such a radical way -

I suppose making it clear that addresses besides the link-locals are
out of scope for IPV6CP would be helpful.  (I thought that was clear
enough from the existing text, but clearer still likely isn't wrong.)

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 20 Jul 2007 00:40:49 +0200

> http://www.ietf.org/internet-drafts/draft-ietf-ipv6-over-ppp-v2-03.txt

I read this draft and I find it severely lacking. At the very least,  
to make using IPv6 over PPP even remotely usable, it should include  
the following options:

1. An MTU option. I know there is an MTU option for IPv4 over PPP but  
I can't find the specification real quick, it doesn't seem to be PPP  
spec but not in the IPCP spec either, or there must be a terminology  
issue such that searching for "MTU" is unsuccessful. But the IPv6 MTU  
shouldn't be tied to the IPv4 MTU anyway. All hardware imposes limits  
on packet sizes, and without a method to explicitly negotiate these  
limits implementations are forced to assume very conservative  
defaults. Routers can advertise an MTU option in RAs but hosts can't,  
a full negotiation is needed here.

2. DNS resolver addresses. Without the ability to resolve names IPv6  
is unusable.

I was thinking that it would be good if multiple full IPv6 addresses  
could be negotiated over IP6CP but upon further reflection that would  
quickly become prohibitively complex or slow: if addresses are  
negotiated one at a time, it would be too slow, and negotiating a set  
would be complex because individual addresses may be generated and  
retired at any time. So using standard IPv6 mechanisms would be  
better here.

But addresses used on the PPP link itself aren't all that  
interesting. A more pressing need is the one for a mechanism to  
negotiate a prefix that a router that terminates the PPP link on the  
client side can use on its LAN interface. I.e.:

     1           2                   3         4
host --<ether>-- customer PPP router --<PPP>-- ISP PPP router -- 
<internet>--

Currently, the interface identifiers in IP6CP and standard autoconfig  
allow for the creation of addresses 3 and 4, but what we really need  
is a prefix that holds addresses 1 and 2.

I can't stress enough that IPv6 over PPP in its current form is as  
good as unusable in practice, and this draft doesn't fix that.

---

From: Ole Troan <[email-masked]>
Date: Thu, 19 Jul 2007 23:52:04 +0100

> do that for Ethernet, so why would PPP be special?

I second that. the whole point of ND not being ARP was to allow for the
same provisioning mechanisms to be used on multiple media. lets not go
down the IPCP rathole.

before we redesign the rest of IPv6. have we reached consensus on the
original question yet?  i.e is it required that an IPv6 node before
communicating with another node performs reachability detection using
NS/NA?

to me it is pretty clear that answer has to be no. in common deployments
a node doesn't know the next-hop address anyway.

if a clarification is needed to emphasise that the neighbour discovery
protocol must be supported on any multicast capable link, then I will
not object to that.

/ot

---

From: Ole Troan <[email-masked]>
Date: Thu, 19 Jul 2007 23:58:35 +0100

> I read this draft and I find it severely lacking. At the very least, to make
> using IPv6 over PPP even remotely usable, it should include  the following
> options:
>

RFC1661, MRU option.

> 2. DNS resolver addresses. Without the ability to resolve names IPv6 is
> unusable.

use the same mechanism as on any other IPv6 link. i.e DHCP.

> I was thinking that it would be good if multiple full IPv6 addresses could be
> negotiated over IP6CP but upon further reflection that would  quickly become
> prohibitively complex or slow: if addresses are  negotiated one at a time, it
> would be too slow, and negotiating a set  would be complex because individual
> addresses may be generated and  retired at any time. So using standard IPv6
> mechanisms would be  better here.
>
> But addresses used on the PPP link itself aren't all that interesting. A more
> pressing need is the one for a mechanism to  negotiate a prefix that a router
> that terminates the PPP link on the  client side can use on its LAN
> interface. I.e.:
>
>     1           2                   3         4

DHCP prefix delegation.

> I can't stress enough that IPv6 over PPP in its current form is as good as
> unusable in practice, and this draft doesn't fix that.

none of the arguments you've put against PPP don't also equally apply to
any other IPv6 link type. and we already have the solutions.

/ot

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 20 Jul 2007 01:27:00 +0200

>>> RFC1661, MRU option.

Ah, ok, that's an LCP option so it covers the hardware side of  
things. Still better to have different maximum packet sizes for v4  
and v6, though.

> use the same mechanism as on any other IPv6 link. i.e DHCP.

That's insanity. I'm not even going to bother discussing such nonsense.

> DHCP prefix delegation.

Well, I don't have to implement this stuff so maybe I shouldn't  
complain. But if I did, I know that I wouldn't want to implement both  
versions of DHCPv6, include moon phase sensors to decide which  
variant to use and then execute it after I've done PPP and stateless  
autoconfig negotiations if the alternative is defining one little new  
NCP option.

>> good as

> any other IPv6 link type. and we already have the solutions.

Wearing a protocol designer hat that's true, if you don't mind  
running a bunch of protocols, wearing an operator or end user hat you  
only see boxes that talk to each other and then fail to do for IPv6  
what they've been able to do for IPv4 for the past decade and a half.  
We only have a bunch of partial solutions and the parts don't fit  
together particularly well even in theory, and not at all in practice  
in current implementations.

But apparently nobody feels responsible for the thing as a whole. My  
conclusion is that if you want to do IPv6 over PPP, you should run  
IPv4 over PPP and then tunnel the IPv6 over IPv4. Anything else only  
leads to headaches.

---

From: James Carlson <[email-masked]>
Date: Thu, 19 Jul 2007 20:36:49 -0400

> things. Still better to have different maximum packet sizes for v4  

That sounds like an IP configuration issue, not a PPP issue.  PPP
simply negotiates link MRU in both directions and reports that to the
network layers above (IPv4 and IPv6).  Those network layers can then
do whatever's appropriate for them.

Having a special MTU option just for IPv6 almost certainly wouldn't
fly in the pppext group.

> That's insanity. I'm not even going to bother discussing such nonsense.

Why is using an existing, well-understood, and well-supported protocol
for its intended purpose "insanity?"

The pppext working group has considered PPP extensions for several
application layer protocols (such as DNS and SIP) multiple times, and
working group consensus has rejected those options every time for
exactly the same reason: BOOTP and DHCP work fine on PPP, and they're
already-defined protocols.  We don't need multiple conflicting
mechanisms to do the same job.

The only exception to this is the Microsoft-proprietary individual
submission that was published as RFC 1877.  Many implementations
grudgingly support this because of MS market power, but it's a brutal
hack, and I doubt similar things will get through.

The previous poster is right; DHCP is the correct answer here.

> autoconfig negotiations if the alternative is defining one little new  

I think this should be taken to the pppext list -- after you've read
through the archives, of course.

DHCP works fine on PPP links.  BOOTP over SLIP was in use *LONG*
before PPP ever showed up, for just this purpose.

"One little new NCP option" completely ignores the architectural
issues here, which include keeping duplicate configuration information
on DHCP servers in sync with PPP servers (hard in a non-trivial
deployment), figuring out what a PPP router should do with the options
(when the real client is well behind the router), and, of course,
deployment (nothing currently implements such an option, though many
systems already have both PPP and DHCP).

Quite intentionally, we do not invent new mechanisms when there are
old ones that will serve the purposes adequately well, because
complexity is the enemy.  This is one of those cases.

> in current implementations.

That sounds like an implementation quality issue, not a protocol
issue.

> IPv4 over PPP and then tunnel the IPv6 over IPv4. Anything else only  

... and that sounds like FUD.  Many of us have been using IPv6 over
PPP for years, without the sorts of "headaches" you're talking about.

In any event, I think your complaints about PPP itself would be better
addressed within the PPP Extensions working group.  I don't think
you'll find the support you're looking for there, but at least the
group has a better history with these very issues.

---

From: james woodyatt <[email-masked]>
Date: Fri, 20 Jul 2007 12:17:20 -0700

On Jul 19, 2007, at 17:36, James Carlson wrote:
>> But apparently nobody feels responsible for the thing as a whole.  
>> My conclusion is that if you want to do IPv6 over PPP, you should  
>> run IPv4 over PPP and then tunnel the IPv6 over IPv4. Anything  
>> else only leads to headaches.
>

It might be worth noting here the reason that Apple AirPort Extreme  
802.11n base stations have a patch to their PPPoE stacks to prevent  
negotiation of IP6CP.

Some PPPoE access concentrators in service with ISP's today refuse to  
negotiate IPCP properly if IP6CP is also attempted.  Rather than work  
around that failurage, we just disable native IPv6 over PPPoE, and we  
tunnel IPv6 over IPv4 just like Mr. van Beijnum suggests.  We are  
unaware of any commercial IPv6 over PPPoE service providers today,  
and nobody has filed any bugs against the AirPort base station  
regarding this decision.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 20 Jul 2007 22:09:30 +0200

On 20-jul-2007, at 2:36, James Carlson wrote:

>> Still better to have different maximum packet sizes for v4
>> and v6, though.

> That sounds like an IP configuration issue, not a PPP issue.

Isn't that what the NCPs are for, to provide the necessary glue  
between the base PPP and what the layer 3 protocol needs?

> Having a special MTU option just for IPv6 almost certainly wouldn't

Why not?

> for its intended purpose "insanity?"

Discussing why you're not discussing something kinda defeats the  
purpose.

But let me observe that this isn't the way how things work for IPv4  
either.

> exactly the same reason: BOOTP and DHCP work fine on PPP,

Not really. Those need a server, which means that if you want to use  
them on a point-to-point link, the other side of that link MUST  
support bootp/dhcp/dhcpv6, if not as a full server then as a relay.  
And again, running IPv4 and everything that that customarily entails  
(DNS) over PPP doesn't require DHCP. Moreover, DHCP support in  
current IPv6 implementations is extremely limited.

> and they're

The notion that DHCPv6 is a "conflicting mechanism" for IPv6 over PPP  
makes no sense at all.

> before PPP ever showed up, for just this purpose.

So what you're saying is that there was no reason to implement PPP in  
the first place?

I've come to know the IETF as a rather conservative place but I've  
never seen it get this bad.

> complexity is the enemy.  This is one of those cases.

Have you read the DHCPv6 spec?

Running DHCPv6, stateless autoconfig and IP6CP each to do a little  
part of a bigger whole is MUCH more complex than simply making IP6CP  
do it all. (Although I can see how using stateless autoconfig would  
be preferable to implementing negotiation of multiple addresses with  
different lifetimes in IP6CP. However, negotiating a prefix to be  
delegated would be simple enough.)

> That sounds like an implementation quality issue, not a protocol

A protocol is a set of interactions designed to do something useful.  
Having several protocols that together are capable of doing said  
useful thing isn't enough, someone has to specify how it all ties  
together. One way to solve that would be a document (written under  
the IETF umbrella or otherwise) that specifies how different  
protocols work together, but in this particular case extending one  
protocol so it can do what's required in most typical installations  
makes much more sense to me.

> PPP for years, without the sorts of "headaches" you're talking about.

Does one end receive address configuration from the other end? I'm  
willing to bet this isn't the case. Sure, shuttling the packets back  
and forth works just fine. But SLIP could do that, too.

> group has a better history with these very issues.

I'm already on way too many mailinglists. I've sent feedback to the  
draft author(s) and I'm willing to provide further feedback if  
desired but that has to be it for this subject.

---

From: srihari varada <[email-masked]>
Date: Sun, 22 Jul 2007 22:00:49 -0400

The subject took a detour from its original context
of the need for address resolution through the Neighbor Discovery
protocol.

The author is appreciative of the belated feedback though the last call
for its parent draft (draft-ietf-ipv6-over-ppp-v2.txt)  took
place a few years ago with the draft by itself was a result of the
collaborative effort of the IPv6 community (please check the archives
of IPv6 WG dating back to 2004).

The encouraging aspect, however, is that framework of the draft-ietf-ipv6-over-ppp-v3.txt
specification allows for extensibility in the IPv6CP protocol
through the definition of new configuration options. Please find the
following statement to this effect in the said draft specification.

"The only IPV6CP option defined in this
document is the Interface Identifier.  Any other IPV6CP configuration
options that can be defined over time are to be defined in separate
documents."

If you strongly feel the need for option extensions,
it can be done so through new I-D(s). The value proposition of these
option extensions can then be discussed. As it is, the suggested
extensions are out of the scope of the specification.

Regards,

Srihari Varada

Iljitsch van Beijnum wrote:

Never mind, I found what's 2462bis. I got
hold of

retired at any time. So using standard IPv6 mechanisms would be  better
here.

But addresses used on the PPP link itself aren't all that  interesting.
A more pressing need is the one for a mechanism to  negotiate a prefix
that a router that terminates the PPP link on the  client side can use
on its LAN interface. I.e.:

1           2                   3         4

host --<ether>-- customer PPP router --<PPP>-- ISP PPP
router -- <internet>--

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Mon, 23 Jul 2007 11:17:50 +0900

it was repeatedly pointed out by Steve Deering and folks in pppext wg
	that:
	- they would like to simplify PPP and tons of PPP options in v4 was
	  a big mitake
	- global address assignment, resolver IPv6 address information and
	  other info has to be passed by DHCPv6 or DHCPv6-lite

	i do not want to see another round of the battle.  we had it enough
	in 1998-2000 timeframe.

itojun

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 22 Jul 2007 22:21:44 -0500

> 	i do not want to see another round of the battle.  we had it enough

It has been repeatedly pointed out by ME that PPP for IPv6 as it  
exists today (in a context where DHCPv6 servers and clients and  
operational procedures to make them work together don't exist on a  
sufficiently wide scale and not to mention the differing  
interpretations on the use of ND/RA) so PPP for IPv6 isn't used to  
any measurable degree. Hence the return of investment on writing the  
specifications and implementations is close to zero.

Answering the questions of whether this constitutes a problem, and if  
so, whether it should be fixed, and if so, how, are left as an  
exercise for the reader.

---

From: James Carlson <[email-masked]>
Date: Mon, 23 Jul 2007 07:16:42 -0400

> between the base PPP and what the layer 3 protocol needs?

They're supposed to provide the necessities, not just random features
that "might" be interesting on a particular implementation.  In this
case, other link layers (such as Ethernet) neither supply nor need
this special IPv6-only MTU feature, so why should PPP need it?

> > Having a special MTU option just for IPv6 almost certainly wouldn't

As above; it's not needed on other link layers, so it'd be surprising
to see it in PPP.  You're certainly welcome to propose it in the PPP
extensions working group, of course, to see what the rest of the folks
there think.

> Discussing why you're not discussing something kinda defeats the  

I don't think that's true at all.  It keeps you from inventing
"solutions" to problems that are in fact already solved.

> But let me observe that this isn't the way how things work for IPv4  

Are you referring to RFC 1877?  If so, then please do note that the
document wasn't a product of the PPP extensions working group.  It was
an individual submission from a Microsoft engineer.  It describes a
Microsoft-proprietary "feature" that negotiates name server addresses
(an application-layer issue) in PPP.

It sets no precedent.

> support bootp/dhcp/dhcpv6, if not as a full server then as a relay.  

Correct.  That "server" consists of sending and receiving simple UDP
messages.

The rest of the "server" is *EXACTLY* the configuration information
that you would have put into PPP.

Thus, I claim that if you can do this for PPP, you can just as easily
do it for BOOTP.

> current IPv6 implementations is extremely limited.

That's not a good reason to invent yet another protocol that (by
definition) is not implemented anywhere.  The PPP change you're
talking about is in fact a new protocol.  Nobody has this feature
today.  It's thus even worse than DHCPv6.

> The notion that DHCPv6 is a "conflicting mechanism" for IPv6 over PPP  

I never said such a thing.

DHCPv6 is a conflicting mechanism for configuring application layer
protocols (such as DNS) via PPP.

DHCPv6 doesn't conflict with IPv6 over PPP.  It just conflicts with
your proposal to negotiate DNS addresses and other such unnecessary
bits.

> So what you're saying is that there was no reason to implement PPP in  

Of course not.  Please see above.  There is no reason to use PPP as a
dumping ground for random things that it "could" negotiate.

> never seen it get this bad.

One of us clearly doesn't understand how IETF protocols are designed.

> Have you read the DHCPv6 spec?

You could say that.

I designed, implemented, and shipped the DHCPv6 implementation on
Solaris.  As part of doing that, yes, I read the DHCPv6 specification
many times.

> delegated would be simple enough.)

I suggest you take the argument to the PPP extensions working group.
This isn't the right place for this argument.

However, in real implementations, designers will end up being *forced*
to implement both the PPP-based hack that you're suggesting along with
DHCPv6.  They'll end up with both mechanisms in order to be maximally
interoperable with the rest of the systems in the field, which may end
up using either of the two mechanisms.

Worse still, systems that implement both will need to figure out how
to arbitrate between conflicting results.  What if PPP gives you one
DNS server, but DHCP gives you another?  Which one is "right?"

That's a poor outcome, and much more complex than the simple solution,
which is to use the existing, already defined, and (in many places)
already implemented solutions.

> makes much more sense to me.

If you want to write a BCP, feel free to do so.  However, if you're
talking about adding functional duplication into PPP, then (A) this
mailing list isn't the right place to discuss it and (B) you're going
to have quite an uphill battle.

I _strongly_ recommend that you search the PPP extensions working
group mailing list archives.  We've dealt with this issue many times
in the past.

> and forth works just fine. But SLIP could do that, too.

I'm not sure I understand the question.

You get an 'Interface-Identifier' that's guaranteed to be unique for
the link, which the PPP implementation then hands over to IPv6 to form
link-local addresses.

What problem do you see?  Is it a problem in assigning addresses with
a different scope?  If so, then that problem exists on all link
layers.  You have to have one system configured to be a "router" and
handing out prefixes via RAs so that the other can form global scope
addresses and/or run DHCPv6.  PPP isn't different here.

> I'm already on way too many mailinglists.

If it helps, it's extraordinarily low traffic, because PPP itself is a
mature technology.  We have only a couple of discussions per year.

> I've sent feedback to the  

In that case, I give up.  I've tried to help.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 23 Jul 2007 10:13:08 -0400

Let's clear the air. I agree with Srihari's email on IPV6CP and new
options. Now let's see what the PPP interop issues are:

The sender PPP node is ND compliant when it issues a unicast NS for NUD
before sending any data. The PPP peer of this sending node has a bug as
to why the peer is not responding with an NA? Let's focus on this
interop issue rather than asking for 2461bis or PPP to be changed. 

It's an orthogonal issue to ask if one should change 2461bis that
requires an IPv6 node to perform reachability detection before
communicating with another node. As for any changes needed by PPP and
IPV6CP, do note, DHCPv6 cannot be used for other options and addresses
in PPP if the client is SLAAC.

Hemant

-----Original Message-----
From: Ole Troan (otroan) 
Sent: Thursday, July 19, 2007 6:52 PM
To: James Carlson
Cc: Hemant Singh (shemant); [email-masked]; JINMEI Tatuya / ????;
[email-masked]; Dave Thaler
Subject: Re: Neighbor Discovery and PPP links

/ot

---

From: James Carlson <[email-masked]>
Date: Mon, 23 Jul 2007 10:55:55 -0400

Hemant Singh (shemant) writes:
> options.

So do I.  Those issues are just out of scope.

> Now let's see what the PPP interop issues are:
> 

Agreed.  And unless there's text that supports this non-answering
mode, that certainly sounds like a bug to me.

I'm not sure that every implementation bug necessarily deserves to be
enshrined as normative "don't make this mistake" text in an RFC.  If
others (particularly those who are refusing to send NAs when
solicited) feel otherwise, then it doesn't bother me to have
additional "must respond" text as long as it doesn't muddy the rest of
the document by making it appear as though normal responses are
otherwise optional in other cases.

> in PPP if the client is SLAAC.

It seems to work fine for me.  Set the RA 'M' bit to zero, the 'O' bit
to one, and the prefix 'A' and 'L' bits to one.  That gets me
interface addresses via stateless address autoconfiguration along with
configuration parameters (but not addresses) via DHCPv6.

In fact, RFC 3315 states (among many notes on interoperation):

   stateful autoconfiguration.  Compatibility with stateless address
   autoconfiguration is a design requirement of DHCP.

It seems to have been designed to work that way.  Why would it be
assumed not to work?

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 23 Jul 2007 11:40:39 -0400

James, 

The topic under discussion is how does a SLAAC PPP client acquire an
IPv6 address using DHCPv6? Yes, stateless DHCPv6 can be used to dole out
options to the SLAAC client but you cannot have the SLAAC client obtain
an IPV6 address with stateless DHCPv6. Sorry, I wasn't clear like so in
my earlier email.

Hemant  

-----Original Message-----
From: James Carlson [mailto:[email-masked]] 
Sent: Monday, July 23, 2007 10:56 AM
To: Hemant Singh (shemant)
Cc: Ole Troan (otroan); [email-masked]; JINMEI Tatuya / ????;

> The sender PPP node is ND compliant when it issues a unicast NS for 
> NUD before sending any data. The PPP peer of this sending node has a 
> bug as to why the peer is not responding with an NA? Let's focus on 
> this interop issue rather than asking for 2461bis or PPP to be
changed.

Agreed.  And unless there's text that supports this non-answering mode,
that certainly sounds like a bug to me.

I'm not sure that every implementation bug necessarily deserves to be
enshrined as normative "don't make this mistake" text in an RFC.  If
others (particularly those who are refusing to send NAs when
solicited) feel otherwise, then it doesn't bother me to have additional
"must respond" text as long as it doesn't muddy the rest of the document
by making it appear as though normal responses are otherwise optional in
other cases.

It seems to work fine for me.  Set the RA 'M' bit to zero, the 'O' bit
to one, and the prefix 'A' and 'L' bits to one.  That gets me interface
addresses via stateless address autoconfiguration along with
configuration parameters (but not addresses) via DHCPv6.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 23 Jul 2007 12:35:34 -0400

James,

I am saying when the M bit is clear, then a node cannot acquire an
address using DHCPv6. However, I agree with you DHCPv6 is much better
alternative than PPP. 

Now, I'd like to focus the discussion back to how will the PPP peer
(which is a server) going to fix the bug when this peer hasn't responded
to the NUD unicast NS? I have already said the source PPP client that
issued the unicast NS is 2461bis complaint. 

Hemant

-----Original Message-----
From: James Carlson [mailto:[email-masked]] 
Sent: Monday, July 23, 2007 12:18 PM
To: Hemant Singh (shemant)
Cc: Ole Troan (otroan); [email-masked]; JINMEI Tatuya / ????;

Hemant Singh (shemant) writes:
> IPv6 address using DHCPv6?

Using stateful DHCPv6 (with the RA 'M' bit set to one), of course.

> Yes, stateless DHCPv6 can be used to dole out options to the SLAAC 
> client but you cannot have the SLAAC client obtain an IPV6 address 
> with stateless DHCPv6.

If you're trying to assign addresses via stateful means (DHCPv6 is the
defined stateful addressing mechanism for IPv6), it's unclear to me why
you'd ever want stateless DHCPv6 as a solution.  It seems like a
contradiction in terms.

It is, though, possible to use stateless and stateful address assignment
in parallel if one wishes, and (to the previous posters
comments) DHCPv6 also works fine in a stateless context to provide the
"other" configuration parameters, even when all addresses in use are
either stateless or are manually configured.

It's a simple request-response mechanism, and no more troublesome to
implement than adding yet another PPP option -- though the architectural
issues are substantially different.  The architecture differs because
PPP messages themselves cannot be 'routed' or proxied, but DHCP messages
can, meaning that DHCP also serves nodes located _behind_ the PPP
termination point, but additional PPP options cannot.
That alone makes a PPP-based solution to the (off-topic) issues raised
by the other poster much less attractive, regardless of its supposed
"simplicity."

---

From: James Carlson <[email-masked]>
Date: Mon, 23 Jul 2007 12:17:46 -0400

> Yes, stateless DHCPv6 can be used to dole out
> an IPV6 address with stateless DHCPv6.

If you're trying to assign addresses via stateful means (DHCPv6 is the
defined stateful addressing mechanism for IPv6), it's unclear to me
why you'd ever want stateless DHCPv6 as a solution.  It seems like a
contradiction in terms.

It is, though, possible to use stateless and stateful address
assignment in parallel if one wishes, and (to the previous posters
comments) DHCPv6 also works fine in a stateless context to provide the
"other" configuration parameters, even when all addresses in use are
either stateless or are manually configured.

It's a simple request-response mechanism, and no more troublesome to
implement than adding yet another PPP option -- though the
architectural issues are substantially different.  The architecture
differs because PPP messages themselves cannot be 'routed' or proxied,
but DHCP messages can, meaning that DHCP also serves nodes located
_behind_ the PPP termination point, but additional PPP options cannot.
That alone makes a PPP-based solution to the (off-topic) issues raised
by the other poster much less attractive, regardless of its supposed
"simplicity."

---

From: James Carlson <[email-masked]>
Date: Mon, 23 Jul 2007 12:41:47 -0400

Hemant Singh (shemant) writes:
> (which is a server)

Nit: PPP doesn't define "client" or "server."  It's peer-to-peer.

> going to fix the bug when this peer hasn't responded

I don't think it should "fix" the problem.  If the peer fails to
respond as expected, it has to declare the remote address to be
unreachable.

I'm not sure why we'd necessarily expect the side that's working right
to work around bugs in the other side.  (In fact, it could be argued
that this is a good state of affairs: malfunctioning gear may in fact
have other bugs, and it's better to detect this early rather than
later.)

Yes, it'd be possible to carve out a hole in NUD and say that if
there's _never_ a response from the peer to any NS for the life of the
link, and if the link is specifically point-to-point and without link
layer addresses, and if the link-layer is known to perform keepalive-
like operation, then the NS sender could "assume" that the address is
actually reachable.

That seems like needless complexity to me, though.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 23 Jul 2007 13:08:33 -0400

James,

Please see in line below with "<hs>".

-----Original Message-----
From: James Carlson [mailto:[email-masked]] 
Sent: Monday, July 23, 2007 12:42 PM
To: Hemant Singh (shemant)
Cc: Ole Troan (otroan); [email-masked]; JINMEI Tatuya / ????;

<hs> I know PPP is a p2p model. I was using the term server to refer to
the server bug in the PPP Interop problem that Dave explained. This is
what Dave said:

[Actually after some more investigation, I think I understand the source
of the interoperability issue.  The core issue is that some PPP servers
actually handle multiple PPP connections to different clients via a
common interface.  Hence from the server's perspective, it's not a
point-to-point link, but rather an NBMA link.  From the client's
perspective, the client thinks it's a point-to-point link, and there's
no way to discover that the server thinks otherwise.]

> going to fix the bug when this peer hasn't responded to the NUD 
> unicast NS? I have already said the source PPP client that issued the 
> unicast NS is 2461bis complaint.

I don't think it should "fix" the problem.  If the peer fails to respond
as expected, it has to declare the remote address to be unreachable.

<hs> But the peer is reachable in this p2p model !

Yes, it'd be possible to carve out a hole in NUD and say that if there's
_never_ a response from the peer to any NS for the life of the link, and
if the link is specifically point-to-point and without link layer
addresses, and if the link-layer is known to perform keepalive- like
operation, then the NS sender could "assume" that the address is
actually reachable.

<hs> Let's not start preparing text for changes to 2461bis for PPP
unless we can first discuss what to do about the server bug that Dave
pointed out.

Hemant

---

From: James Carlson <[email-masked]>
Date: Mon, 23 Jul 2007 13:20:26 -0400

> the server bug in the PPP Interop problem that Dave explained. This is

Yes; I saw that.  Part of the disconnect here is in the use of NBMA as
a representation of a collection of PPP links.  That seems like one of
the real hazards.

> no way to discover that the server thinks otherwise.]

I think that's yet more reason to treat all links as equal and use the
same procedures everywhere.

However, even if we got this issue cleared up, I think there's still a
problem with the NBMA representation.  From the server's point of
view, the clients all must have some sort of link-layer address so
that they can be distinguished.  From the client's point of view, no
such address is known or knowable.

This implies that the client cannot create reasonable response because
it cannot fill in the SLLA option correctly.  Either the server's
NBMA-synthesizing code needs to fix this up, or it's going to take yet
more hacks to the neighbor discovery state machine to make it run
right.  (Essentially assuming that these NBMA peers have already-known
addresses.)

> <hs> But the peer is reachable in this p2p model !

Some bugs can result in a lack of connectivity.  This looks like one
of them.

My question here is why this specific bug should be considered special
enough that we ought to carve out exceptions in order to make it
work.  Why is that?  If some system had gotten the checksum
computation or byte order wrong in some field, we wouldn't write
workarounds for those errors as well, would we?

> unless we can first discuss what to do about the server bug that Dave

I'm not trying to prepare any changes for 2461bis, except to show how
complicated it would be in order to carve out the exception that I
think you're proposing here.