Iljitsch van Beijnum writes: > 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?
They're supposed to provide the necessities, not just random features that "might" be interesting on a particular implementation. In this case, other link layers (such as Ethernet) neither supply nor need this special IPv6-only MTU feature, so why should PPP need it? > > Having a special MTU option just for IPv6 almost certainly wouldn't > > fly in the pppext group. > > Why not? As above; it's not needed on other link layers, so it'd be surprising to see it in PPP. You're certainly welcome to propose it in the PPP extensions working group, of course, to see what the rest of the folks there think. > >>> 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. I don't think that's true at all. It keeps you from inventing "solutions" to problems that are in fact already solved. > But let me observe that this isn't the way how things work for IPv4 > either. Are you referring to RFC 1877? If so, then please do note that the document wasn't a product of the PPP extensions working group. It was an individual submission from a Microsoft engineer. It describes a Microsoft-proprietary "feature" that negotiates name server addresses (an application-layer issue) in PPP. It sets no precedent. > > 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. Correct. That "server" consists of sending and receiving simple UDP messages. The rest of the "server" is *EXACTLY* the configuration information that you would have put into PPP. Thus, I claim that if you can do this for PPP, you can just as easily do it for BOOTP. > 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. That's not a good reason to invent yet another protocol that (by definition) is not implemented anywhere. The PPP change you're talking about is in fact a new protocol. Nobody has this feature today. It's thus even worse than DHCPv6. > > 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. I never said such a thing. DHCPv6 is a conflicting mechanism for configuring application layer protocols (such as DNS) via PPP. DHCPv6 doesn't conflict with IPv6 over PPP. It just conflicts with your proposal to negotiate DNS addresses and other such unnecessary bits. > > 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? Of course not. Please see above. There is no reason to use PPP as a dumping ground for random things that it "could" negotiate. > I've come to know the IETF as a rather conservative place but I've > never seen it get this bad. One of us clearly doesn't understand how IETF protocols are designed. > > 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? You could say that. I designed, implemented, and shipped the DHCPv6 implementation on Solaris. As part of doing that, yes, I read the DHCPv6 specification many times. > 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.) I suggest you take the argument to the PPP extensions working group. This isn't the right place for this argument. However, in real implementations, designers will end up being *forced* to implement both the PPP-based hack that you're suggesting along with DHCPv6. They'll end up with both mechanisms in order to be maximally interoperable with the rest of the systems in the field, which may end up using either of the two mechanisms. Worse still, systems that implement both will need to figure out how to arbitrate between conflicting results. What if PPP gives you one DNS server, but DHCP gives you another? Which one is "right?" That's a poor outcome, and much more complex than the simple solution, which is to use the existing, already defined, and (in many places) already implemented solutions. > >> 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. If you want to write a BCP, feel free to do so. However, if you're talking about adding functional duplication into PPP, then (A) this mailing list isn't the right place to discuss it and (B) you're going to have quite an uphill battle. I _strongly_ recommend that you search the PPP extensions working group mailing list archives. We've dealt with this issue many times in the past. > >> 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. I'm not sure I understand the question. You get an 'Interface-Identifier' that's guaranteed to be unique for the link, which the PPP implementation then hands over to IPv6 to form link-local addresses. What problem do you see? Is it a problem in assigning addresses with a different scope? If so, then that problem exists on all link layers. You have to have one system configured to be a "router" and handing out prefixes via RAs so that the other can form global scope addresses and/or run DHCPv6. PPP isn't different here. > > 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. If it helps, it's extraordinarily low traffic, because PPP itself is a mature technology. We have only a couple of discussions per year. > 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. In that case, I give up. I've tried to help. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
