February 2003 - ipv6-wg - mailman.ripe.net

RE: [ipv6-wg@ripe.net] IPv6, future internet, hierarchy
by Michel Py 14 Feb '03

14 Feb '03

Gert, >> Michel Py wrote: >> available for that. What Gert wants is a large number of >> bits to make the subnet number look good, in the *subnet* >> bits, > Gert Doering wrote: > Call it "look good", but at least you understand the goal. > I appreciate that. Don't get me wrong: the goal (like any naming convention) is good (although operational experience suggests that in this very case it will be useless after a few years). This is not the point. The point is that you think that you can use the IID bits for routing purposes. This discussion has come five times on the table in the last 10 years and has always ended in the hole. In a nutshell, what you want is to declare that the IID bits could have a mixed use, either as IID bits or as subnet bits. Sharing the IID bits for routing purposes is not a good idea, and we just don't have enough bits to do what you want otherwise. > At least four people have voiced here that they are doing this, > and I'm pretty sure that many more networks are doing non-/64s > on point-to-point links for similar or other reasons) As Randy and I said before, the ipv6 WG would be the place to discuss addressing architecture issues. I will clue you though that what some call the "old guard" includes lots of very knowledgeable people with CONSIDERABLE operational experience, including a number of people that have tried what you suggest before with other protocols. Large address spaces such as IPv6 are nothing new to some of us. More than a decade ago, I was dealing with a lot of Novell/IPX networks. The IPX address is 80 bits, 48 IID bits and 32 subnet bits (Hex notation same as IPv6). We did see a lot of funny subnets numbers such as "BABE4B0B" and a few other more explicit ones that I can't really mention here. They were contests to name subnets in the good old IPX days. Anyway, at the time these 32 subnet bits were more than enough to do what you are suggesting for IPv6, some people including myself actually tried, and after reorganizing and merging networks it becomes meaningless. In short: Nice idea, bit a) it does not work in the long run, we tried it before and b) even if it did the benefits that it brings are not worth running the IID bits in mixed mode anyway. Michel.

2 1

RE: [ipv6-wg@ripe.net] IPv6, future internet, hierarchy
by Michel Py 14 Feb '03

14 Feb '03

Stephane, > Stephane Bortzmeyer wrote: > 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. Yes, it is better when you *can*. > Otherwise, "serious" operators would not name their > routers with sensible names like > P12-0.NYKCR2.New-york.opentransit.net This takes 296 bits, btw. It is done because it *can* be done because it's a name, and that's exactly what names have been designed for. Not IP addresses. This is not the issue anyway: We are not talking about configuring the MAC address with a structure that is meaningful; this can be done already and there are 62 bits available for that. What Gert wants is a large number of bits to make the subnet number look good, in the *subnet* bits, totally ignoring conservation. Where does this come from? Nobody does that except him, nobody does it in v4, it has never been part of v6. We can't allow end-sites to do that kind of thing, they would all need at least 48 subnet bits as well. Michel.

3 2

RE: [ipv6-wg@ripe.net] IPv6, future internet, hierarchy
by Michel Py 14 Feb '03

14 Feb '03

Christian, >> 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 theIID or privacy extensions. > Christian Schild wrote: > 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. I don't agree. Look at a supposedly private cross-country frame-relay link. It _appears_ to be a point-to-point link. From the router's standpoint, you don't know if there's one frame-relay switch between you and the other end, or twenty; you don't know if traffic stays within the frame-relay cloud or is tunneled into IP or carried over ATM. You don't even know how many carriers are involved. It's not a lot more secure than going over the public internet and if you are security conscious you will encrypt end-to-end traffic and use the BGP MD5 option. These ptp links are the exact target of work being done that include things such as embedding the crypto key or part of it in the MAC address. Michel.

2 1

[ipv6-wg@ripe.net] Browsers
by Priyaupnp＠netscape.net 13 Feb '03

13 Feb '03

hi all, pls let me know what are the ipv6 enabled browsers which can be installed in linux. Thanks in advance Pria __________________________________________________________________ The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/

6 5

RE: [ipv6-wg@ripe.net] IPv6, future internet, hierarchy
by Michel Py 13 Feb '03

13 Feb '03

> Andrius Kasparavicius wrote: > And at the end, would I be bad if I will use /127 > for point-to-point(tunnels). VERY bad. Not only there are known issues with doing this, but it violates both RFC2373 and its replacement draft-ietf-ipngwg-addr-arch-v3-11.txt. Not respecting IETF _standards_ is not a good idea in any case and at some point people that think they are gods and can have their own standard will have to renumber their entire network. Michel.

4 3

RE: [ipv6-wg@ripe.net] IPv6, future internet, hierarchy
by Michel Py 13 Feb '03

13 Feb '03

> Daniel Karrenberg wrote: > 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. Yep. After a while it becomes more misleading than anything else. Michel.

1 0

Re: [ipv6-wg@ripe.net] IPv6, future internet, hierarchy
by Christian Schild (JOIN Project Team) 13 Feb '03

13 Feb '03

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

1 0

RE: [ipv6-wg@ripe.net] IPv6, future internet, hierarchy
by Michel Py 13 Feb '03

13 Feb '03

> 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.

4 3

RE: [ipv6-wg@ripe.net] IPv6, future internet, hierarchy
by Michel Py 13 Feb '03

13 Feb '03

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.

5 4

RE: [ipv6-wg@ripe.net] IPv6, future internet, hierarchy
by Michel Py 12 Feb '03

12 Feb '03

Gert, > Gert Doering wrote: > Hummm? You're a bit confused about left and right? Doh! > 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. Yes, but to a reasonable extent. Following your logic, you will soon need 16 more bits to accommodate 32-bit ASNs, then it would also be nice to have some bits to say if the customer's router a Cisco or a Juniper or Linux, some other bits so match the link type, and speed, and so on. It never ends, because each network has specific needs. I hear what you say; it would be elegant just by looking at the prefix to be able to tell something about it. In the end though, it does not replace network documentation which is paramount for operations. When I troubleshoot a route, I will lookup in the database anyway to see where it goes, over what kind of link, etc. There's stuff you can't put in the address, such as billing. Example: the customer calls the NOC whining being down. He's down because he has not paid. Yes, you could put in the interface description that it was shutdown by Joe because of billing issues, but I'd rather have the telco CktID there. If your NOC tech does a no shut without looking up the database and customer info, you're wasting money because someone else will waste more time shutting it down another time. This is all about good operational practices: if your documentation and change management are good, you don't need that kind of trick. You want to know what a prefix is about? Lookup the database, it will tell you what you need and possibly things you might not have thought about, such as billing. > My numbering plan requires AS number, router ID and link > number in the network part for each point-to-point link. This is what is flawed, IMHO. You basically say that you want 48 bits out of the address space just to have subnet numbers that look neat. If the IPv6 address was 256 bits that would have been possible but not with 128 bits. Michel.

2 1