RE: [ipv6-wg@ripe.net] IPv6, future internet, hierarchy
Gert,
Gert Doering wrote: I just want to point out that this discussion is *not* about tunnels only. It's about generic addressing plans for point to-point links, and the failure of /64s to address the needs of *ops* types.
This discussion does not belong here. The RIRs responsibilities are what's on the right of /64, not what's on the left.
Unfortunately, ISP networks usually consist of *many* point-to point links, and all of them want to be addressed in a structured and time-saving (!) way. Which means "use some of the available bits to do structure" - and if you use up a /64 per link, you need those bits further up, and those are just not there in the current policy frame work.
Oh really? Mmmm, how many of the 4 billion /64s you have been allocated do you need? By my account, a network with 60k subnets including 1/3rd of ptp and loopbacks fits in a /44, including loss to internal aggregation.
(If the RIR->LIR allocation/assignment framework is changed to hand a /16 to every LIR, such a scheme might not be a problem. In the current scheme, it is).
If you can demonstrate that you need more than a /32, you might get it. Show us the numbers. Michel.
Hi, On Wed, Feb 12, 2003 at 12:19:09PM -0800, Michel Py wrote:
Gert Doering wrote: I just want to point out that this discussion is *not* about tunnels only. It's about generic addressing plans for point to-point links, and the failure of /64s to address the needs of *ops* types.
This discussion does not belong here. The RIRs responsibilities are what's on the right of /64, not what's on the left.
Hummm? You're a bit confused about left and right? However: what would be the right forum to do this discussion? v6ops seems to be about other things, and the other IPv6 related WGs at IETF seem to be shutdown or dead. I didn't start the discussion here, but I think that it's not overly off-topic. People reading this list are trying to *deploy* IPv6, and as such, problems show up.
Unfortunately, ISP networks usually consist of *many* point-to point links, and all of them want to be addressed in a structured and time-saving (!) way. Which means "use some of the available bits to do structure" - and if you use up a /64 per link, you need those bits further up, and those are just not there in the current policy frame work.
Oh really? Mmmm, how many of the 4 billion /64s you have been allocated do you need? By my account, a network with 60k subnets including 1/3rd of ptp and loopbacks fits in a /44, including loss to internal aggregation.
You don't read what we are writing. We want to include AS numbers in the addressing scheme for point to point links (= 16 bits lost), and sequence numbers (another 16 bits, for ease of addressing). So if you do /64s on ptp links, plus 2 times 16 bits for enumeration, you need a /32 to handle all your point to point links. Add a router number (16 bits), you'd even need a /16 for this. Yes, of course this fictuous /16 would be very sparsely populated. But this is what IPv6 is all about, isn't it? Give people a big enough address space so that they can do things the *easy* way, instead of the conservative way. Allocate sparsely, and make use of the address space. Of course wasting a /16 for ptp addressing is ridiculous. This is why creative people have thought up schemes to put those bits for "router id, remote as, link number" into the fields that are to the *right* of the /64. And voila, all your ptp links in *one* /64, which can then be nicely filtered on border routers, and will be sufficient for however big your network is going to be.
(If the RIR->LIR allocation/assignment framework is changed to hand a /16 to every LIR, such a scheme might not be a problem. In the current scheme, it is).
If you can demonstrate that you need more than a /32, you might get it. Show us the numbers.
See above. My numbering plan requires AS number, router ID and link number in the network part for each point-to-point link. If you force me to use a /64 for those, I need a /16 for my infrastructure (and a couple of additional /16s for my customers' networks, of course). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 56029 (55671) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Wed, Feb 12, 2003 at 09:31:05PM +0100, ext Gert Doering wrote:
Hi,
On Wed, Feb 12, 2003 at 12:19:09PM -0800, Michel Py wrote:
Gert Doering wrote: I just want to point out that this discussion is *not* about tunnels only. It's about generic addressing plans for point to-point links, and the failure of /64s to address the needs of *ops* types.
This discussion does not belong here. The RIRs responsibilities are what's on the right of /64, not what's on the left.
Hummm? You're a bit confused about left and right?
However: what would be the right forum to do this discussion? v6ops seems to be about other things, and the other IPv6 related WGs at IETF seem to be shutdown or dead.
I didn't start the discussion here, but I think that it's not overly off-topic. People reading this list are trying to *deploy* IPv6, and as such, problems show up.
This is certainly a discussion that one can have on this list. We are a list that talks about technical issues related to getting ipv6 deployed. That sometimes means that we can find that there is an operational problem with a standard - at other times, policies of the RIRs might make our life more difficult. In either case, it is certainly within our charter to report problems and to talk about solutions, and to bring them to the attention of the IETF when it is about standards and to the lir working group when it is about policy. David K. chairperson ---
On Wed, Feb 12, 2003 at 09:31:05PM +0100, Gert Doering wrote:
We want to include AS numbers in the addressing scheme for point to point links (= 16 bits lost), and
Be prepared for 32-bit ASN. [not that I think that including the remote ASN in the transfer network addressing is a particular good idea, but that's a differnt topic] Best regards, Daniel
On 12.02 21:31, Gert Doering wrote:
... We want to include AS numbers in the addressing scheme for point to point links (= 16 bits lost), and sequence numbers (another 16 bits, for ease of addressing). So if you do /64s on ptp links, plus 2 times 16 bits for enumeration, you need a /32 to handle all your point to point links. Add a router number (16 bits), you'd even need a /16 for this. ...
I'll admit that I do not follow the details of this discussion but I want to offer a bit of general advice based on considerable operational experience: Overloading layer three addresses with clever numbering schemes never works in the long run. Why? As netowrks grow the room for "structure" in adresses will constrict. Lower layer technology will change underneath the numbering scheme. Higher layer technology will change above the numbering scheme. Network design will change .... somewhere, somehow. ;-) If you are not convinced yet, look at the "evoloution" of any arbitrary telephone numbering plan. What "structure" should L3 addresses have then? L3 addresses should closely reflect L3 routing domains. That's all! Not more, not less. To amplify: L3 addresses should be designed to closely reflect present and *future* L3 routing domains. The art in making addressing plans is to use the "structure" part such that routing structure can easily be added later. This involves leaving a number of bits unused in strategic places. It certainly does not mean to cram as much information in the address as possible to make it "easier to read". Addresses should be read through a network design database. I think vendors will learn that qickly with those long addresses. Is the IETF doing any standardisation work in this area? Maybe it should. Daniel
participants (5)
-
Daniel Karrenberg -
Daniel Roesen -
David Kessens -
Gert Doering -
Michel Py