On Wed, 25 Aug 2010 00:55:34 -0400 Christopher Morrow <christopher.mor...@gmail.com> wrote:
> On Mon, Aug 23, 2010 at 5:38 PM, Mark Smith > <i...@69706e6720323030352d30312d31340a.nosense.org> wrote: > > On Mon, 23 Aug 2010 17:23:09 -0400 > > Jared Mauch <ja...@puck.nether.net> wrote: > > > >> > >> On Aug 23, 2010, at 4:49 PM, Mark Smith wrote: > >> > >> > On Mon, 23 Aug 2010 09:55:48 -0400 > >> > Jared Mauch <ja...@puck.nether.net> wrote: > >> > > >> >> > >> >> On Aug 23, 2010, at 9:17 AM, Mark Smith wrote: > >> >> > >> >>> On Mon, 23 Aug 2010 14:11:04 +0200 (CEST) > >> >>> sth...@nethelp.no 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? No I'm not. If somebody was to ask me what my advice was I'd recommend /64s for all links. I'd also point out the issue that /127s is trying to mitigate. I'd point out that I think there are feasible solutions that properly address this issue for all link types. I'd then recommend that if they want to use /127s, they reserve a /64 for those links, so that if and when those solutions become available, they can merely change the prefix length back to /64. > 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. > What I'm against is unnecessary complexity, because, to quote "anonymous" on slashdot, "complex = more things that can break". Variable length interface identifiers, if they're unnecessary, only create more complexity and therefore more things that can break. If the interface identifier is universally the same size, then it'd be pretty hard for people to get the size wrong. The other thing that complexity creates is more choice. Technical people like choice. The problem with too much choice, however, is choice paralysis. If there are too many choices, it can become too risky to make one. With too much choice, it may not be possible to adequately weigh up the positive and negative consequences of all of the choices, and in particular the consequences of making a wrong choice. So not making a choice becomes less risky than making the wrong one. So, if we have /64s everywhere, and have them not vulnerable to issues that /127s mitigates (but only on point-to-point links), then I think /127s are unnecessary. That's one less unnecessary complexity. > > > >> >> 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? It's likely to be the common model. It's the simplest and most widely available option because it uses no more than the basic IPv6 RA/PIO mechanism and SLAAC, and therefore would be a baseline functionality expectation in both CPE and customer aggregation routers. > 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, No I don't use them, as mentioned earlier. > that seems to fit with your requirements as well, yes? > > -chris -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
