> The interesting thing is, one person's PI is another person's PA. > By that I mean, that the difference between PI and PA, is subjective.
yes. > The general idea is that the bulk of address assignments used should be, > one would expect and hope, PA, and aggregated, into large assignments > of PI blocks (ideally one per ASN) in the DFZ. The scalability of the > DFZ depends on this, in fact. no. while it's true in the current system that identity-follows-routing, that may not always be true, and away from the DFZ, it's already untrue. therefore we must reject the aggregation-centric view, or at least, constrain it to only being valid for globally connected devices, reachable from DFZ. consider an ipv6-reachable light switch in my house. does anyone still think that it can have "end to end" connectivity, so that if i want to monitor it or control it while on vacation, i'll send IPSEC-signed datagrams from my hotel room to do so? that i'll subject it to every DDoS attack, stack smash attack, IPSEC key guessing attack, plus any other attacks i can't think of or which havn't been invented yet? or do we think that it'll sit in fe80:: and be talked to only by some local (hardened) proxy? or that at best it'll have a ULA-G address, reachable by my household security company's local embedded network but no further? i'm not saying the DFZ will go out of style. i'm saying that when we fill half of the IPv6 address space with light switches and toasters and security cameras and music players, we'll have 18446744073709551616 endpoints, of which only a handful are "hardened enough" to be allowed to be globally reachable. so in contrast to the current IPv6 addressing plan where 0/0 is the DFZ other than a few cutouts like fe80:: and fc00::, if we were going to be realistic about how stuff was actually going to be connected in this BCP38-free world, we'd've allocated beef::/16 to the DFZ and assumed that the rest of IPv6 would be used by non-DFZ devices. fortunately, the difference between 120 bits and 128 bits is minor compared to the magnitude of the 120 bit mantissa available in my ULA-G proposal. so, the fact that the addressing plan assumes "DFZ uber alles" is no great waste. on the other hand, i like where you went with this, so i'll quote it all in hopes that those who didn't read it the first time will read it now: > On the other hand, PA is a form of "lock-in". Renumbering is painful, > if the scope of the renumbering is large. > > If a PA assignment is directly to an "end user", e.g. an enterprise, > this in theory isn't likely to be a large scope, or is at least manageable. > > It is when the PA assignments are further subassigned, that the scope > becomes a significant issue, and the pain (of renumbering) grows. yea, verily. tell it, brother! > For example, if a large PA block has been given out, and further assigned > to hundreds of customers (of the PA block recipient), each of which has > DNS servers "on the block", if the recipient needs to renumber, the pain > is prohibitive. > > Placing the potential recipient in the position of having to choose between > PA, and a difficult-and-costly-to-obtain PI block, is by its nature harmful > to the deployment of IPv6. as it has been for IPv4, but people coped because there was a legacy swamp. in the absence of a legacy swamp, the PI/PA split has a chilling effect on IPv6 deployment, over and above the chilling effect of the technology and training costs. > And it is for this reason that I advocate reducing or eliminating costs, and > relaxing the requirements for receiving PI space. For instance, deferring > the costs of PI space until the PI block is added into the DFZ, is one > option. i'm not saying whether i agree or disagree with this proposal. i'll merely remind you, again, that IETF doesn't set PI policy, that's a regional thing and you'll need to follow jordi to all the RIR meetings and make your proposals to the actual decisionmakers, who are the members of various RIRs. > And admittedly, it is the interactions of 1:1 NAT and DNS that causes most > of the problems, under any scheme for handling relocation in connectivity > to the DFZ. 1:1 NAT is only a predictable problem if you think the DFZ will always be the dominant form of communication. when i finally get my Dick Tracy Tv Wrist Watch and i make a wrist-to-wrist call to someone in my same city, you can bet that my wireless provider and the other-end wireless provider are going to have private peering, and that ULA-G would work just fine for us. and that in the long distance use case, the LCR algorythm will choose some city-local proxy who might or might not use DFZ on the backside, but i most likely won't be using the DFZ on my own behalf. > In a hierarchy of PI-PA assignments, it fundamentally does not matter > whether the PA block itself is being sub-assigned, or if a separate PI block > from which 1:1 NATv6 is instead PA'd and sub-assigned. agreed. nor would it matter if the 1:1 NATv6 was to a ULA-G address block. > The fact that 1:1 NAT isn't strictly a two-tier technology, and that the > total amount of theoretical address space is so immense, even when used in > a particularly inefficient manner, means that doubling or tripling the > effective use (by heavy use of 1:1 NAT), is not a significant cost. > > Use of 1:1 NAT keeps the DFZ to a bare minimum, while still giving all the > flexibility for back-door networking at arbitrary scale. yup. > Still, the question of what to use for the other side of NAT is important, > at least in terms of what kinds of solutions to promote, to support in > the IETF protocol and address specifications, and in the RIR policies. > > What I propose is, that PI assignment be very significantly relaxed and > promoted, for use in this case. you're making this particular case to the wrong audience. > Why? > > Because, use of ULA-C for the other side of PA NATing means that should > an organization at some point need to have multihomed connectivity, the > site would need to renumber. This is because (stating the obvious) only > PI blocks can be announced into the DFZ, and ULA-C are specifically not > allowed into the DFZ. you're assuming that someone with ULA-G and 1:1 NAT won't find a comfortable equilibrium with their ISP whereby their use of PA avoids all lock-in issues. why? (isn't this the holy grail of eid/loc separation?) > If, on the other hand, any organization that foresees, at any point in > time, needing to be multihomed, getting PI space early and using it, > with NATv6 into PA space (for access to the DFZ), all is good. i don't think an organization has to be able to foresee this in order for all to be good. in fact, in your 1:1 NAT case and with some simplistic assumptions about LCR, multihomed ULA-G might be able to perfectly coexist with a perfectly-aggregated DFZ. though we're way off topic by this time. > The fact that this scales recursively is also good. Each link in the > chain is a PA to PI mapping (NATv6). And every enterprise in the tree under > a PI in the DFZ, while having its own PI block, while it is single homed, > is still aggregated into a single PI block in the DFZ. that would work as well as anything else that's been proposed and better than most. (though there's the detail of PI vs. ULA-G and the fact that IETF is the wrong forum to talk about PI.) > So, the scalability of the DFZ is still limited by growth of entities > which require their own PI block, and renumbering is accomplished by > changing, as opposed to establishing, NATv6 at the single-homed PI block's > edge (upstream towards DFZ PA block). And eventually, removing NATv6 > and announcing the PI block directly into the DFZ. i don't get that last part. you're assuming that a 200-megaroute DFZ is coming to earth within our lifetimes? but other than that last part i'm ready to drink this particular koolaid, as long as "require their own PI block" is semantically equivilent to "owns global POSIP backbone and does peering and transit in many major markets", which i think it probably is. > So, what kind of PI blocks should be made available? (wrong audience. visit [EMAIL PROTECTED] to start, then follow jordi.) > In summary: > > Having an easily available third option (beyond PA and ULA-C), is something > that I think is important to remove the impediment to migration and/or > deployment of IPv6 on a large scale (numbers of entities deploying as well > as size of entities.) my summary: ULA-G does everything you want, but can actually be argued here in ipv6@ rather than having to make new coherent global RIR policy. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
