RE: Neighbor Discovery and PPP links

["Hemant Singh (shemant)" <[e-mail]>]

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:[e-mail]] 
Sent: Wednesday, July 18, 2007 12:56 AM
To: James Carlson
Cc: Dave Thaler; [e-mail]; [e-mail]
Subject: Re: Neighbor Discovery and PPP links

At Tue, 17 Jul 2007 16:35:33 -0400,
James Carlson <[e-mail]> wrote:

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

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.
					[e-mail]

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

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