Re: Neighbor Discovery and PPP links

On 19-jul-2007, at 23:50, Hemant Singh (shemant) wrote:

> 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

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.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------