- ipv6-wg - mailman.ripe.net

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

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

12 Feb '03

Robert, >> Michel Py wrote: >> +-----+---------+---------+-------+--------------+ >> | 8 | 16 | 16 | 8 | 16 | >> | | hostid | | index | routernumber | >> +-----+---------+---------+-------+--------------+ >> 02 ca : fe FF : FE 77 : beef > Robert Kiessling wrote: > I'm talking about network address derived from router number > and some local interface index. This is not possible in the > 16 bits available in the assignment. I don't understand; there are 40 bits in the example? (and I could have squeezed 6 more). > cisco3640(config-if)#mac-address ca.fe77.beef > Changing the MAC address to get an easily usable IP address > seems quite perverse to me. Indeed it is, but this was the long way to demonstrate how it is derived. And is besides the point, as we were talking about tunnels and they don't have a MAC address of their own, so you can go ahead and directly configure an EIU-64 or modified-EUI-64 IPv6 address directly as show in the short way. Michel.

2 1

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

12 Feb '03

Sam, > Sam Wilson wrote: > It's an odd feature of that RFC that it's published as > Informational rather then Proposed Standard, Which RFC are you referring to? 2373 is in the standards track and so is draft-ietf-ipngwg-addr-arch-v3-11.txt which is going to obsolete 2373 soon. >> [RFC2373] >> Network Working Group R. Hinden >> Request for Comments: 2373 Nokia >> Obsoletes: 1884 S. Deering >> Category: Standards Track Cisco Systems > and the only reference to the RFC 2119 terms "MUST", "MUST NOT" etc. > is in the Introduction. It specifically does not say: > "Interface IDs are REQUIRED to be 64 bits long and to be > constructed in IEEE EUI-64 format [EUI64]." > Perhaps someone who is further into the the IETF process can say > whether this was an oversight or if the latitude was intended. I can't speak for the authors in terms of intent, but the fact of the matter is that if it said "REQUIRED" there would be no compliant implementation today, which would forbid the standards track. This very point has actually been appealed recently, so regardless of the intent the latitude is necessary as of today. This an egg-and-chicken problem: there are a lot of legacy tunnels that use /127, and software developers don't want to enforce the /64 boundary because it would force legacy networks to renumber, which can't happen overnight so the likely result is that almost no one would use the updated software which is no good for a protocol under development such as IPv6. This is largely a user education problem, because the old reflexes of using a /30 or a /31 that are justified in v4 are not required anymore for v6. Michel.

1 0

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

12 Feb '03

> Do the ops types include people like me who worry that every > time a NIC has to be replaced it's going to require changes > to DNS, ACLs and anything else that's keyed on IP address? Mmm, I don't know. I'm the kind of ops type that also reads RFCs and understand the importance of respecting standards. From an operational standpoint, it pays off in the long run. I would never configure a server or router with an IPv6 address that includes some part of the BIA, but I try to respect standards too, and even the current standard could be respected although its clumsiness definitely makes modified EUI-64 desirable. Michel.

1 0

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

12 Feb '03

Robert, > There are a number of advantages of non-/64 for p2p. For example, > you can have an easy address allocation scheme like ...: > <routernumber>:<index>:<host id>" which does not require any > bookkeeping. That's not possible with /64 addresses. You are completely mistaken. Using your own example: Hostid = 0xcafe Index = 0x77 Routernumber = 0xbeef I'll even go over an EUI-64/RFC2373 example although it's going to be obsolete real soon. +-----+---------+---------+-------+--------------+ | 8 | 16 | 16 | 8 | 16 | | | hostid | | index | routernumber | +-----+---------+---------+-------+--------------+ 02 ca : fe FF : FE 77 : beef The long way: ------------- cisco3640#conf t cisco3640(config)#inte e0/0 cisco3640(config-if)#mac-address ca.fe77.beef cisco3640(config-if)#ipv6 address 2001:db8::/64 eui-64 cisco3640(config-if)#end cisco3640#sh ipv6 inte e0/0 Global unicast address(es): 2001:DB8::2CA:FEFF:FE77:BEEF, subnet is 2001:DB8::/64 ^^ ^^ ^^ ^^^^ \\|| || |||| CAFE 77 BEEF The short way: cisco3640#conf t cisco3640(config)#inte e0/0 cisco3640(config-if)#ipv6 address 2001:db8::02CA:FEff:fe77:BEEF/64 This is compliant with EUI-64 and RFC 2373. As I said before, we're talking about straight EUI-64 here and this is soon to be obsoleted. The replacement for RFC2373 (draft-ietf-ipngwg-addr-arch-v3-11.txt) uses _modified_ EUI-64, and you can do almost whatever you want, such as: ipv6 address 2001:db8::02CA:FE00:0077:BEEF/64 ipv6 address 2001:db8::02:CAFE:77:BEEF/64 ipv6 address 2001:db8::1/64 All of which are compliant modified EUI-64 addresses. > The standard also requires EUI-64 addresses which is clearly > not desirable for a number of application. For example, it would > be very silly to require a change all your peering sessions just > because you change your NIC. There is no relation. You can construct an EUI-64 or a modified EUI-64 address without using the BIA, what's your problem here? Michel.

2 1