RE: [ipv6-wg@ripe.net] IPv6, future internet, hierarchy
Gert Doering wrote: (And because it makes maintenance and setup much easier,
We call that troubleshooting with the seeds of the pants, which exactly what serious operators don't do.
as I don't have to go to some place to find a "get me a free subnet", I just can have the machine assign it ad-hoc, just by telling it the router name/id and the interface name.
This a disaster waiting to happen. A subnet is documented in a subnet database, not in the router's config; the first thing to do *before* configuring a subnet is to create the db record and populate it. Not maintaining proper documentation is cause for termination in lots of shops. Engineering with the seeds of the pants again.
We *have* the address space,
No we *don't*. The IETF standards are decided by consensus, and the IID bits are not yours to play with for routing purposes. There are other legitimate uses for these 64 bits, such as embedding some crypto in the IID or privacy extensions.
Of course it is very much possible with 128 bits. People *do* this, so it's possible, isn't it?
I will laugh when you have to renumber because suddenly a new security protocol that uses 56 of the 64 IID bits is required.
The thing that is not possible is to accommodate for that inside the very narrow-minded "one size fits all" mind-set that made the rule that one should use a /64 on a point-to-point link.
This is called "standardization". That's why you can plug a refrigerator, a microwave oven and a cell phone charger in the same power outlet. The microwave takes 10,000 times more power than the cell phone charger, and indeed the wiring for a power outlet that could accommodate only cell phone chargers would be a lot lighter. Do you want 20 types of power plugs in your data center?
There is no reason (except "one size fits all") *for* that rule - or at least nobody in this discussion named one - but many good reasons *against* it.
This has been debated before and the IETF has decided otherwise. People that maintain correct network documentation do not need nor desire fancy allocation schemes. Often, these same people that maintain correct documentation respect standards, btw. Michel.
All, Am Mittwoch, 12. Februar 2003 23:47 schrieb Michel Py:
No we *don't*. The IETF standards are decided by consensus, and the IID bits are not yours to play with for routing purposes. There are other legitimate uses for these 64 bits, such as embedding some crypto in the IID or privacy extensions.
please, we are talking about point-to-point links here. Michel, what you say (and what is written in the draft) is perfectly reasonable, when thinking about a 'real' link. I think a PtP link is some kind of an exception. There is nothing 'inside' a PtP link, just a source and a destination. The only reason to use a subnet for such a link, is a better management. So why should a piece of software or a software developer rely on the fact, that there is a /64 on a PtP link. Again, it is correct to expect this from a usual link, but not from a PtP link. Maybe the ADDRARCH draft is flawed and it should clearly exclude PtP links when requiring a /64. So long, Christian
Hi, a final reply from me, now that things really get ridiculous...: On Wed, Feb 12, 2003 at 02:47:39PM -0800, Michel Py wrote:
Gert Doering wrote: (And because it makes maintenance and setup much easier,
We call that troubleshooting with the seeds of the pants, which exactly what serious operators don't do.
Serious operators don't reject things that can aid in network setup and management just because some ivory tower research declares it isn't "pure". [..]
We *have* the address space, No we *don't*.
Of course we have. The *space* is there. There are some rules in the way, but that doesn't mean the space suddenly disappears.
The IETF standards are decided by consensus, and the IID bits are not yours to play with for routing purposes. There are other legitimate uses for these 64 bits, such as embedding some crypto in the IID or privacy extensions.
Privacy extensions? On a *point-to-point* link? Now your're getting *really* ridiculous. We're not talking about customer access (they can have a /64 or a /48 just fine) but about backbone lines or tunnels. As for the crypto-in-the-IID - I don't see this happen in the near future for point-to-point links (it might well happen for end-to-end connections), so I'm not very much worried about this.
Of course it is very much possible with 128 bits. People *do* this, so it's possible, isn't it? I will laugh when you have to renumber because suddenly a new security protocol that uses 56 of the 64 IID bits is required.
Required by whom? If *we* decide to implement "some new security protocol" on *point-to-point links* in *our network*, we will have lots of work to do anyway with router deployment tests, router upgrades and so on. This is not going to "suddenly happen upon us". End-to-End security (for systems sitting in some LAN, happily using /64s) is not affected by what the transport layer in between is doing, as long as the transport layer isn't changing packets (which it isn't doing).
The thing that is not possible is to accommodate for that inside the very narrow-minded "one size fits all" mind-set that made the rule that one should use a /64 on a point-to-point link.
This is called "standardization". That's why you can plug a refrigerator, a microwave oven and a cell phone charger in the same power outlet. The microwave takes 10,000 times more power than the cell phone charger, and indeed the wiring for a power outlet that could accommodate only cell phone chargers would be a lot lighter. Do you want 20 types of power plugs in your data center?
Bad example. To use your model: actually we are *not* using 1000 Ampere plugs for everything just because the "same plug for everything". It's ok to standardize certain things - I don't object here - but it's tremendously helpful if standards reflect reality.
There is no reason (except "one size fits all") *for* that rule - or at least nobody in this discussion named one - but many good reasons *against* it.
This has been debated before and the IETF has decided otherwise.
From what I read in Randy's e-mail, I'm not overly convinced that there is/was overly strong consensus here.
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 02:47:39PM -0800, Michel Py <michel@arneill-py.sacramento.ca.us> wrote a message of 56 lines which said:
This a disaster waiting to happen. A subnet is documented in a subnet database, not in the router's config;
Clearly, it is not so simple. While you cannot encode *everything* even in 128 bits (billing status), it is better when you can encode at least a few things. Otherwise, "serious" operators would not name their routers with sensible names like P12-0.NYKCR2.New-york.opentransit.net, they would use undecipherables IDs like GG667V23NM.opentransit.net and lookup in a database... (How convenient when you are stuck in a data center with a borrowed PC screen and the database is protected.)
I will laugh when you have to renumber because suddenly a new security protocol that uses 56 of the 64 IID bits is required.
There are two sort of mistakes you can do with numbering plans. Some may affect other operators and therefore they have the right to shout at you in RIPE mailing lists and meetings. Other mistakes may affect only you and therefore, while every normal human being will appreciate friendly advices, I would prefer that remarks about this sort of "mistakes" stay calmer.
participants (4)
-
Christian Schild (JOIN Project Team) -
Gert Doering -
Michel Py -
Stephane Bortzmeyer