On Mon, Aug 23, 2010 at 5:38 PM, Mark Smith <[email protected]> wrote: > On Mon, 23 Aug 2010 17:23:09 -0400 > Jared Mauch <[email protected]> wrote: > >> >> On Aug 23, 2010, at 4:49 PM, Mark Smith wrote: >> >> > On Mon, 23 Aug 2010 09:55:48 -0400 >> > Jared Mauch <[email protected]> wrote: >> > >> >> >> >> On Aug 23, 2010, at 9:17 AM, Mark Smith wrote: >> >> >> >>> On Mon, 23 Aug 2010 14:11:04 +0200 (CEST) >> >>> [email protected] wrote: >> >>> >> >>>>> These mechanisms are applicable to any type of link, would preserve the >> >>>>> simplicity of universal 64 bit IIDs and the other benefits of them e.g. >> >>>>> CGAs, as well as avoiding the ping-pong problem. >> >>>> >> >>>> IMHO, the "universality" of 64 bit IIDs went down the drain the moment >> >>>> router vendors allowed longer than 64 bit netmasks to be configured. >> >>>> >> >>> >> >>> So how does that prevent those prefix lengths being changed to /64? >> >> >> >> Because you would then end up with overlapping address space that is >> >> unreachable in a production deployment. >> >> >> > >> > Not necessarily. If I were to deploy /127s, I'd be allocating /64s to >> > the links. >> >> You may put a /64 on your /127 links in addition, but most people only put >> one IP subnet on a link, otherwise they might want redirects ;) >> > > I meant reserving a /64 for the link and then configuring a /127 prefix > length on it. If my concerns about /64s were resolved, all I'd need to > do would be change the prefix length back to a /64.
this means you're already doing what the draft is asking to codify? So, in short you support the idea of the draft you just have some reservations about it covering all the bases you feel are important. > >> >> But that would be an operational item and not an standards body item? >> >> >> > >> > This has been cross posted to v6ops. >> >> Operationally the vendors may be violating some RFC, so lets publish what is >> relevant and working today so we can all move on? We can deal with >> any additional updates and items with "how IPv6" works elsewhere or in a >> new document so we can move /127 on p2p links along? >> > > So that leaves the problem still existing on network edge LANs and > virtual P2P links between customer aggregation routers and CPE, of > which there'l be millions. Maybe you, Steinar and Randy don't > have to worry about those types of links, but others of us do. are cable/dsl providers going to provision each p2p link to the end customer with a /64? won't that just be 2 off-link /128's (today I see mostly 2 off-link /32's I think?) and PD to send down the prefix the operator decides is appropriate for in-home use? If so, the /127 discussion isn't involved here, I think. > A complete solution would solve the problem for all link types, not > just mitigate it for point-to-point links in the backbone. I think the only thing that's being addressed in this one draft is codifying what's happening in practice today. So that vendors don't accidentally 'fix' the 'bug' that permits /127's to work just fine. since you stated earlier you already do this, that seems to fit with your requirements as well, yes? -chris -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
