Iljitsch van Beijnum writes: > On 20-jul-2007, at 0:58, Ole Troan wrote: > > >>> RFC1661, MRU option. > > Ah, ok, that's an LCP option so it covers the hardware side of > things. Still better to have different maximum packet sizes for v4 > and v6, though.
That sounds like an IP configuration issue, not a PPP issue. PPP simply negotiates link MRU in both directions and reports that to the network layers above (IPv4 and IPv6). Those network layers can then do whatever's appropriate for them. Having a special MTU option just for IPv6 almost certainly wouldn't fly in the pppext group. > >> 2. DNS resolver addresses. Without the ability to resolve names > >> IPv6 is > >> unusable. > > > 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?" 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, and they're already-defined protocols. We don't need multiple conflicting mechanisms to do the same job. The only exception to this is the Microsoft-proprietary individual submission that was published as RFC 1877. Many implementations grudgingly support this because of MS market power, but it's a brutal hack, and I doubt similar things will get through. The previous poster is right; DHCP is the correct answer here. > >> 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. > > > DHCP prefix delegation. > > Well, I don't have to implement this stuff so maybe I shouldn't > complain. But if I did, I know that I wouldn't want to implement both > versions of DHCPv6, include moon phase sensors to decide which > variant to use and then execute it after I've done PPP and stateless > autoconfig negotiations if the alternative is defining one little new > NCP option. I think this should be taken to the pppext list -- after you've read through the archives, of course. DHCP works fine on PPP links. BOOTP over SLIP was in use *LONG* before PPP ever showed up, for just this purpose. "One little new NCP option" completely ignores the architectural issues here, which include keeping duplicate configuration information on DHCP servers in sync with PPP servers (hard in a non-trivial deployment), figuring out what a PPP router should do with the options (when the real client is well behind the router), and, of course, deployment (nothing currently implements such an option, though many systems already have both PPP and DHCP). 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. > 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. > 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. 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. -- 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 --------------------------------------------------------------------
