- ipv6-wg - mailman.ripe.net

[ipv6-wg@ripe.net] IPv6, future internet, hierarchy
by Andrius Kasparavicius 14 Feb '03

14 Feb '03

Hello, what I should think about when I allocate IPv6? :-) Just like IPv4 subnets for needed IP devices, the same but multipled(how much?) for future hierarchy, divide all I have for all who need(best hierarchy). Divide geographically, by organisations, people population for best hierarchy all v6? I look ahead, hierarchy.. a lot of IPv6. Hmm.. And at the end, would I be bad if I will use /127 for point-to-point(tunnels). respectfully, Andrius

7 29

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