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

Reply via email to