[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.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
