> On Tue, 3 Jul 2007, Paul Vixie wrote: >>> 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. > > There are cases where the network administrators dont care about the > global DFZ, aggregation or whatever, they just want enough IP for their > INTERNAL usage. And now are we back to what we (where I work) need ULA-C/G > for... > > - we don't need the full internet connectivity or reachability, we simply > dont care whats on the internet from our point of view. We have RIR > assigned IPblock for _all_ our global needs and let our chosen ISP provide > us global internet when they announce _our_ RIR assigned netblock > - unique addresses so when we interconnect to other organization we dont > get collision ever, neither now or in 10years time. ULA-L simple isnt > enough, 2^40 is not good enough. No point in argueing over that. > - we dont want NAT anywhere in our network, that break the end to end > connectivity we need for lots of things. Our internal video or phone > system or whatever other application we have/will get. > - we need full reverse DNS control over the ULA-C/G blocks we have (we > will get several thousands of them) since that way the other organization > just have to go to the internet root DNS to lookup our IPs, they dont need > to tune their DNS for reaching thing in OUR network.
You are referring to "other organization(s)". Will these be entities to whom you directly connect, or have VPN connections to? Or do you mean, generally, the Internet at large? Without NAT, ULA is *not* allowed into the DFZ. Period. You don't want NAT. You *must* then choose to use PA blocks assigned by ISPs, or your own PI block(s). You may not care about the global DFZ, but if you plan on connecting to it, it certainly cares about you, and everyone else. Specifically, that certain rules be observed, ruthlessly. Everything else goes, however. Once you have your address space, it is yours to do with as you wish. There is no limit to the way you carve it up - google "VLSM" (variable-length subnet mask) to get some good ideas. But what goes into the DFZ is something all members of the DFZ care very greatly about. > (we are looking at something between 500 and upto 10 000 or more unique > ULA-C/G blocks for or network and use) > - ... > > sure we could use PI, but we dont need any of the features on the internet > really... and for those features we need we have our RIR assigned netblock > for that purpose. > > sure we could just get a bigger PA block from our RIR but they dont buy > _OUR_ arguments for why we need more IP, which is okay since it is our > INTENRAL network that required the amount of IP we need. We dont have any > issues to justify that we need a /32 after the current policies, or any of > the other I've seen suggested. You should not be dealing with PA blocks if you have the need for global reverse DNS that you control, and for the size and complexity of your network(s). PI is where you should be looking, and nowhere else. And, since we're discussing ULA, your needs suddenly become irrelevant. Sorry. Thanks for providing your input. > And dont come telling us how we should structure our INTENRAL network, we > have our reasons and our requirments, good or bad from others point of > view, but they are the guidelines we are running our network and business > after.I really doubt anyone like to be told that since it is strictly > internal:) What can you tell us about the needs of each of the 500-10000++ blocks you think you need? Specifically, size (in terms of 2^N hosts per block, with groupings of sizes to the nearest multiple of 8)? E.g. - need 8,000 blocks of 2^8 hosts, 1,500 blocks of 2^16 hosts, and 500 blocks of 2^32 hosts. Even if you have 32,000 blocks of 2^48 hosts, that is still only 2^64 of address space. This would easily be managed by the use of a single /64. If you have *one* PI block, of /64 or larger (e.g. /48 or /32), I think it should be pretty clear that you should be able to subdivide your space in any way you see fit. All of those subdivisions would be internal only, as far as networks carried on anyone's routers - no one outside of your infrastructure would see anything other than your single PI block. > Another reason for not using RIR assigned IP for our internel network > usage are the justification we have to provide for getting a bigger block > from RIPE. Or that it might be harder to explain why we need 500-10000++ > PI blocks from RIPE than to just get ULA-C/G from whoever provide it. RIRs > or IANA direct through a robot. For us it doesnt mather much really, we > just need some UNIQUE IP addresses for our internal usage WITH global > reverse DNS possibility... I believe, if you look carefully, most RIRs have policies that permit the assignment of PI blocks in IPv6 to anyone who *would* qualify for PI block in IPv4 space. And the requirement for PI in IPv4 is certainly something you would qualify for... > I guess other enterprises see this the same way. They simply want INTERNAL > unique IP addresses with global reverse DNS options, nothing less, nothing > more. > They probably wont bother to become LIR just for internal IP, their ISP(s) > provide them with their internet connectivity, and they can probably > easy justify to get PI if they want that. The general argument on ULA-C/ULA-G vs PI is this - PI is what should be used if you want globally unique address space, and will want this to be known (without NAT) on reverse query lookups, to anyone else who is connected indirectly (via the DFZ). The model for ULA-C/ULA-G is one of non-Internet connected networks, or networks who may use Internet-based transparent transport services, such as VPN or MPLS-VPN or whatever else. VPN-VPN connections, which have in the past been referred to as "extra-nets", are what are envisioned. Globally unique addresses used by all such VPNs, mean that interconnnecting them, deliberately or accidentally, permanently or temporarily, just works. And, just because you plan on running an internal network, does not mean that none of that network will want to reach the outside world. If it does, certainly plan on using firewalls, but don't plan on using NAT just because you used NAT in IPv4. There's nothing wrong with mixing ULA address space and PI or PA address space on your internal infrastructure - that too is meant to just work, and might well suit your needs. But if you plan on having everything on your internal network reach out to the internet, my advice is to get a single PI block and use that from the very beginning. Exactly *how* you use that is your business and yours alone. But, the community at large *will* tell you - we do not intend on allowing anyone to get, use, and announce, large quantities of PI *blocks*. The scalability of the DFZ requires very conservative growth and use of numbers of prefixes, regardless of their size. It is router slots, aka prefixes, aka netblocks in the DFZ, that we care about. Nothing in that is impacted by the size of the blocks in question. If you need to have 1000000 blocks internally, that's fine - but those will need to be aggregated by you into one single PI block when you talk to the world, or however many blocks your minimal topological needs can justify. (Or aggregated by one or more ISPs in PA blocks, that's fine too.) Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
