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
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
