On 20-jul-2007, at 2:36, James Carlson wrote:
Still better to have different maximum packet sizes for v4
and v6, though.
That sounds like an IP configuration issue, not a PPP issue.
Isn't that what the NCPs are for, to provide the necessary glue
between the base PPP and what the layer 3 protocol needs?
Having a special MTU option just for IPv6 almost certainly wouldn't
fly in the pppext group.
Why not?
use the same mechanism as on any other IPv6 link. i.e DHCP.
That's insanity. I'm not even going to bother discussing such
nonsense.
Why is using an existing, well-understood, and well-supported protocol
for its intended purpose "insanity?"
Discussing why you're not discussing something kinda defeats the
purpose.
But let me observe that this isn't the way how things work for IPv4
either.
The pppext working group has considered PPP extensions for several
application layer protocols (such as DNS and SIP) multiple times, and
working group consensus has rejected those options every time for
exactly the same reason: BOOTP and DHCP work fine on PPP,
Not really. Those need a server, which means that if you want to use
them on a point-to-point link, the other side of that link MUST
support bootp/dhcp/dhcpv6, if not as a full server then as a relay.
And again, running IPv4 and everything that that customarily entails
(DNS) over PPP doesn't require DHCP. Moreover, DHCP support in
current IPv6 implementations is extremely limited.
and they're
already-defined protocols. We don't need multiple conflicting
mechanisms to do the same job.
The notion that DHCPv6 is a "conflicting mechanism" for IPv6 over PPP
makes no sense at all.
DHCP works fine on PPP links. BOOTP over SLIP was in use *LONG*
before PPP ever showed up, for just this purpose.
So what you're saying is that there was no reason to implement PPP in
the first place?
I've come to know the IETF as a rather conservative place but I've
never seen it get this bad.
Quite intentionally, we do not invent new mechanisms when there are
old ones that will serve the purposes adequately well, because
complexity is the enemy. This is one of those cases.
Have you read the DHCPv6 spec?
Running DHCPv6, stateless autoconfig and IP6CP each to do a little
part of a bigger whole is MUCH more complex than simply making IP6CP
do it all. (Although I can see how using stateless autoconfig would
be preferable to implementing negotiation of multiple addresses with
different lifetimes in IP6CP. However, negotiating a prefix to be
delegated would be simple enough.)
Wearing a protocol designer hat that's true, if you don't mind
running a bunch of protocols, wearing an operator or end user hat you
only see boxes that talk to each other and then fail to do for IPv6
what they've been able to do for IPv4 for the past decade and a half.
We only have a bunch of partial solutions and the parts don't fit
together particularly well even in theory, and not at all in practice
in current implementations.
That sounds like an implementation quality issue, not a protocol
issue.
A protocol is a set of interactions designed to do something useful.
Having several protocols that together are capable of doing said
useful thing isn't enough, someone has to specify how it all ties
together. One way to solve that would be a document (written under
the IETF umbrella or otherwise) that specifies how different
protocols work together, but in this particular case extending one
protocol so it can do what's required in most typical installations
makes much more sense to me.
But apparently nobody feels responsible for the thing as a whole. My
conclusion is that if you want to do IPv6 over PPP, you should run
IPv4 over PPP and then tunnel the IPv6 over IPv4. Anything else only
leads to headaches.
... and that sounds like FUD. Many of us have been using IPv6 over
PPP for years, without the sorts of "headaches" you're talking about.
Does one end receive address configuration from the other end? I'm
willing to bet this isn't the case. Sure, shuttling the packets back
and forth works just fine. But SLIP could do that, too.
In any event, I think your complaints about PPP itself would be better
addressed within the PPP Extensions working group. I don't think
you'll find the support you're looking for there, but at least the
group has a better history with these very issues.
I'm already on way too many mailinglists. I've sent feedback to the
draft author(s) and I'm willing to provide further feedback if
desired but that has to be it for this subject.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
