RE: PPP IPV6 Control Protocol Extensions for Prefix

Soohong Daniel Park writes:
> Soohong Daniel Park writes:
> > I am wondering if this draft should be discussed as an interesting 
> > draft and taked at PPPEXT WG.
> 
> >My vote is "no."
> 
> This draft is originated with draft-ietf-pppext-ipv6-dns-addr-02.txt
> to update RFC 2472.

I understand.

I don't think that one should be published, either.  RFC 1877 wasn't a
good thing, and I don't think we're doing anyone any favor extending
it into IPv6.

> >This draft duplicates functionality already in RFC 2461 (IPv6 Neighbor
> Discovery), and I don't see a reason to allow it here.
> 
> I didn't address prefix advertisement such as NDP. The intent of my
> draft is to address
> a method of obtaining the valid prefix. If the local peer requests an
> invalid prefix,
> the remote peer specifies the prefix by this option, and returing the
> IPv6 valid prefix.

But, unless I'm missing something crucial, that's exactly what NDP
does.  The PPP link will negotiate an IPV6CP Instance-Identifier for
each peer and, when the NCP is Opened, send NDP Router Solicitation
using the link-local address generated from that 64 bit identifier.
If the peer has any prefixes that can be used, it will return these
immediately.

One of the really nice things about this procedure is that it's the
same for every link type, and isn't special for PPP.  Why do we need
another mechanism to do something that already works with the existing
protocols?

Not that I think it's significant, but I suspect that the asymmetric
nature of the proposed option -- it's not negotiated per peer, but
rather per link -- will lead to convergence problems.  The text says
this:

     If the two IPv6 Prefixs are different. a Configure-Nak is sent
     with a valid IPv6 Prefix value suggested for use by the remote
     peer. Such a suggested IPv6 Prefix MUST be valid global Prefix.

That can lead to:

	Peer A                Peer B
  1.	Req prefix=A ->    <- Req prefix=B
  2.	Nak prefix=A ->    <- Nak prefix=B
  3.	Req prefix=B ->    <- Req prefix=A
  4.	Nak prefix=B ->    <- Nak prefix=A
  5.	Req prefix=A ->    <- Req prefix=B
	[...]

1.  Each peer sends its idea of its global prefix.  (Why exactly 1?  I
    have no idea.)

2.  Each peer notes that the prefixes don't match, and sends a Nak.

3.  Each peer accepts the Nak from the other, and switches to a
    different prefix for the link.

4.  Each peer notes that the prefixes still don't match.

5.  Lather, rinse, repeat.

Worse still, the draft does *not* address what is supposed to happen
during renumbering.  What happens when those lifetimes expire?  Does
IPV6CP renegotiate (taking IPV6CP out of Opened state and, due to the
'tld' event in the state machine, bringing the IP connection down in
the process)?  Or do you switch to using the more graceful mechanisms
in RFCs 2461/2462?

-- 
James Carlson, Solaris Networking              <[email protected]>
Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677