Subject: Re: Neighbor Discovery and PPP links

From: srihari varada <[email-masked]>
Date: Mon, 23 Jul 2007 10:29:57 -0400

[here is the email that had posting problems]

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

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

---

From: srihari varada <[email-masked]>
Date: Mon, 23 Jul 2007 11:29:15 -0400

[text formatted reply (July 22, 2007) to van Beijnum is being reposted  
-- apologies for the mix-up]

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:

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