[ipv6-wg@ripe.net] IPv6, future internet, hierarchy
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
In your previous mail you wrote: And at the end, would I be bad if I will use /127 for point-to-point(tunnels). => NO! NO!!! If we'd like to save addresses and not give a /64 to a point-to-point link, please don't use a prefix with a length not equal to 64. Simply don't give other addresses than the (mandatory) link-local addresses, a highly reusable /64 prefix which is the equivalent of unnumbered IPv6 point-to-points. Regards Francis.Dupont@enst-bretagne.fr PS: please read draft-savola-ipv6-127-prefixlen-04.txt
Hi, On Wed, Feb 12, 2003 at 04:48:12PM +0100, Francis Dupont wrote:
In your previous mail you wrote:
And at the end, would I be bad if I will use /127 for point-to-point(tunnels).
=> NO! NO!!! If we'd like to save addresses and not give a /64 to a point-to-point link, please don't use a prefix with a length not equal to 64.
We use /124s for tunnels, which avoid the problems from Pekka's draft (anycast), but doesn't waste /64s needlessly. We have a common /64s that is shared between all ptp links, and in the bits "between" the /64 and the /124 boundary, we encode the AS number of the partner, a sequence number, and so on. Best of both worlds.
Simply don't give other addresses than the (mandatory) link-local addresses, a highly reusable /64 prefix which is the equivalent of unnumbered IPv6 point-to-points.
In a dynamically routed backbone, it's very important to actually *see* which ways a packet travels (traceroute), and occasionally to be able to do hop-by-hop diagnostics. All this requires routed ptp addresses, but there is no need for a /64 here. Especially EUI-64 on ptp links is a real nuisance. 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
In your previous mail you wrote: We use /124s for tunnels, which avoid the problems from Pekka's draft => what is the standard which defines a /124 for a link? (anycast), but doesn't waste /64s needlessly. => we have a French expression for that: �conomie de bouts de chandelles. In a dynamically routed backbone, it's very important to actually *see* which ways a packet travels (traceroute), and occasionally to be able to do hop-by-hop diagnostics. All this requires routed ptp addresses, => no, in fact you simply need a fixed address per router. but there is no need for a /64 here. => there is no choice in the standard: all prefixes on a link are /64s. Especially EUI-64 on ptp links is a real nuisance. => I agree but this is another issue. Regards Francis.Dupont@enst-bretagne.fr
Hi, On Wed, Feb 12, 2003 at 05:09:29PM +0100, Francis Dupont wrote:
In your previous mail you wrote:
We use /124s for tunnels, which avoid the problems from Pekka's draft
=> what is the standard which defines a /124 for a link?
What is the standard that prohibits doing this? There is good reason not to do /126 or /127, but I can't see any strong reason (except "one size fits all", which is never true) to use /64.
(anycast), but doesn't waste /64s needlessly.
=> we have a French expression for that: �conomie de bouts de chandelles.
In a dynamically routed backbone, it's very important to actually *see* which ways a packet travels (traceroute), and occasionally to be able to do hop-by-hop diagnostics. All this requires routed ptp addresses,
=> no, in fact you simply need a fixed address per router.
If you have multiple lines between routers, it can be quite important which of those is used.
but there is no need for a /64 here. => there is no choice in the standard: all prefixes on a link are /64s.
Please quote the RFC that *mandates* /64s for all links. As far as I remember, it's a SHOULD for multiaccess links, and voluntary for ptp links. 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
Hi, On Wed, Feb 12, 2003 at 05:16:21PM +0100, Gert Doering wrote:
but there is no need for a /64 here. => there is no choice in the standard: all prefixes on a link are /64s.
Please quote the RFC that *mandates* /64s for all links. As far as I remember, it's a SHOULD for multiaccess links, and voluntary for ptp links.
OK, I stand corrected, RFC 2373 actually doesn't differenciate between multiaccess and point-to-point links, and requires /64s on every single link (section 2.4 and 2.5.1). --- snip --- In a number of the format prefixes (see section 2.4) Interface IDs are required to be 64 bits long and to be constructed in IEEE EUI-64 format [EUI64]. --- snip --- While I agree that it is written in there, I won't change our current addressing scheme. /64s for point-to-point link is just so useless when compared to other schemes (like "encoding the peer AS number in the network part of the addresses used"). If one wants to do useful addressing with putting /64s on ptp links, it would mean "waste a /44 or so" on transit networks - which isn't permitted either. People, get real. This policy sucks big time. Change it if you cant't live with people not accepting it. (*All* this /64 stuff sucks big time, but for multiaccess networks with up-to-64 bit identifiers [firewire], it makes some certain amount of sense) 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
Please excuse me for butting in - I'm a long time lurker on this list.
On Wed, Feb 12, 2003 at 05:16:21PM +0100, Gert Doering wrote:
but there is no need for a /64 here. => there is no choice in the standard: all prefixes on a link are /64s.
Please quote the RFC that *mandates* /64s for all links. As far as I remember, it's a SHOULD for multiaccess links, and voluntary for ptp links.
OK, I stand corrected, RFC 2373 actually doesn't differenciate between multiaccess and point-to-point links, and requires /64s on every single link (section 2.4 and 2.5.1).
--- snip --- In a number of the format prefixes (see section 2.4) Interface IDs are required to be 64 bits long and to be constructed in IEEE EUI-64 format [EUI64]. --- snip ---
It's an odd feature of that RFC that it's published as Informational rather then Proposed Standard, 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. Sam Wilson Infrastructure Services Division Computing Services, The University of Edinburgh Edinburgh, Scotland, UK
Hi, On Wed, Feb 12, 2003 at 05:05:44PM +0000, Sam.Wilson@ed.ac.uk wrote:
Please excuse me for butting in - I'm a long time lurker on this list.
You're more than welcome, because it brings up an interesting point... [..]
OK, I stand corrected, RFC 2373 actually doesn't differenciate between multiaccess and point-to-point links, and requires /64s on every single link (section 2.4 and 2.5.1). [..]
It's an odd feature of that RFC that it's published as Informational rather then Proposed Standard, 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]."
Thanks for pointing that out. So we're not violating established internet standards here (by using /124s) and we're not going to end in network hell. At least not due to this :-) I've received a few more comments on this in the mean time. For example, some people like to encode router ID and link number in the addressing scheme for point-to-point links, like this: <64bit-prefix>:<router-id>:<link-number>:0:000x/124 which is *really* handy for quick and painless address management. Doing that with a /64 per link (putting router-id and link number further to the left) means "waste a /32", which is certainly not compatible with the current RIPE policies... 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
"Interface IDs are REQUIRED to be 64 bits long and to be constructed in IEEE EUI-64 format [EUI64]." So we're not violating established internet standards here (by using /124s) and we're not going to end in network hell. At least not due to this :-)
there has been some 'discussion' of this in the ietf, with a bit of polarization between the ipv6 protocol old guard and ops types. it has not produced anything useful. randy
[RFC2373 does NOT say] "Interface IDs are REQUIRED to be 64 bits long and to be constructed in IEEE EUI-64 format [EUI64]." So we're not violating established internet standards here (by using /124s) and we're not going to end in network hell. At least not due to this :-)
there has been some 'discussion' of this in the ietf, with a bit of polarization between the ipv6 protocol old guard and ops types. it has not produced anything useful.
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? If not, where do I look to find out why people aren't worried about those things? (And no, dynamic DNS etc doesn't work for us). Sam Wilson Infrastructure Services Division Computing Services, The University of Edinburgh Edinburgh, Scotland, UK
[RFC2373 does NOT say] "Interface IDs are REQUIRED to be 64 bits long and to be constructed in IEEE EUI-64 format [EUI64]." So we're not violating established internet standards here (by using /124s) and we're not going to end in network hell. At least not due to this :-) there has been some 'discussion' of this in the ietf, with a bit of polarization between the ipv6 protocol old guard and ops types. it has not produced anything useful. 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? If not, where do I look to find out why people aren't worried about those things? (And no, dynamic DNS etc doesn't work for us).
i don't know off-hand if it includes you or not. the ietf is open. it is your choice to be included or not. randy
[/64s and whether EUI-64's are required as host IDs] there has been some 'discussion' of this in the ietf, with a bit of polarization between the ipv6 protocol old guard and ops types. it has not produced anything useful. 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? If not, where do I look to find out why people aren't worried about those things? (And no, dynamic DNS etc doesn't work for us).
i don't know off-hand if it includes you or not. the ietf is open. it is your choice to be included or not.
Let me rephrase my question. Could you say whether the issues raised in 'discussion', possibly by the "ops types" you referred to above, are to do with management of support infrastructure if the host ID field is mandated to be derived from the EUI-64 identifier rather than assigned by administrative fiat? Thanks, Sam Wilson Infrastructure Services Division Computing Services, The University of Edinburgh Edinburgh, Scotland, UK
Let me rephrase my question. Could you say whether the issues raised in 'discussion', possibly by the "ops types" you referred to above, are to do with management of support infrastructure if the host ID field is mandated to be derived from the EUI-64 identifier rather than assigned by administrative fiat?
yes. but there is no substitute for clueful folk actually participating constructively in ietf wgs. ops types are fairly sparse voices. RFC 3041 Privacy Extensions for Stateless Address Autoconfiguration in IPv6. T. Narten, R. Draves. January 2001. (Format: TXT=44446 bytes) (Status: PROPOSED STANDARD) may also be relevant. one small bit of progress, painfully won. hey, pekka, you around and care to whine? :-) randy
Sam.Wilson@ed.ac.uk wrote:
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? If not, where do I look to find out why people aren't worried about those things? (And no, dynamic DNS etc doesn't work for us).
See RFC2464 and RFC2373, quote: 8<----------- The motivation for inverting the "u" bit when forming the interface identifier is to make it easy for system administrators to hand configure local scope identifiers when hardware tokens are not available. This is expected to be case for serial links, tunnel end-points, etc. The alternative would have been for these to be of the form 0200:0:0:1, 0200:0:0:2, etc., instead of the much simpler ::1, ::2, etc. ------------>8 Thus 2001:db8::1 is a 'modified' EUI-64 and thus can be assigned. You are just lying a bit that the local scope id is not available and thus you are making it up, but you do correctly set it as per RFC. Also, the network is _yours_ you can do with it whatever you want. It makes your pain bigger when changing prefixes etc. IMHO EUI-64 (read autoconfig) is very handy and useful for hosts, but not for routers or servers and other critical infrastructure. My idea about it is to have the autoconfig still be in effect but configure the 'critical' IP by script/config, this way one can simply deconfigure the IP on one box, while ssh'd to it over it's autoconfigged IP and then configure it on another. Making a poor mans failover possible. Greets, Jeroen
"Interface IDs are REQUIRED to be 64 bits long and to be constructed in IEEE EUI-64 format [EUI64]." So we're not violating established internet standards here (by using /124s) and we're not going to end in network hell. At least not due to this :-)
there has been some 'discussion' of this in the ietf, with a bit of polarization between the ipv6 protocol old guard and ops types. it has not produced anything useful.
Could someone remind me of any reason for using /64s for p-t-p links? - kurtis -
In your previous mail you wrote:
It's an odd feature of that RFC that it's published as Informational rather then Proposed Standard, 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]."
Thanks for pointing that out. => oh the bad faith! So we're not violating established internet standards here (by using /124s) and we're not going to end in network hell. At least not due to this :-) => you are violating established internet standard... which is *really* handy for quick and painless address management. Doing that with a /64 per link (putting router-id and link number further to the left) means "waste a /32", which is certainly not compatible with the current RIPE policies... => you have the whole freedom on 63 bits of the interface ID. I don't understand your argument. Francis.Dupont@enst-bretagne.fr
Hi, On Thu, Feb 13, 2003 at 04:41:29PM +0100, Francis Dupont wrote:
So we're not violating established internet standards here (by using /124s) and we're not going to end in network hell. At least not due to this :-) => you are violating established internet standard...
"established"? I beg to differ. If one were to count, I'd say that there are more point-to-point links out there that are NOT using /64s than otherwise.
which is *really* handy for quick and painless address management. Doing that with a /64 per link (putting router-id and link number further to the left) means "waste a /32", which is certainly not compatible with the current RIPE policies...
=> you have the whole freedom on 63 bits of the interface ID. I don't understand your argument.
I have more than one link. 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
So we're not violating established internet standards here (by using /124s) and we're not going to end in network hell. At least not due to this :-)
=> you are violating established internet standard...
Maybe the standard is broken? How come that we have a problem with letting people announcing longer prefixes, but we are not worried about address conservation... - kurtis -
In your previous mail you wrote: People, get real. This policy sucks big time. Change it if you cant't live with people not accepting it. => sorry but the last call on the address architecture document is closed! Regards Francis.Dupont@enst-bretagne.fr PS: addresses on firewire/i-link/ieee 1394 are *not* 64 bit long (:-)!
Hi, On Thu, Feb 13, 2003 at 12:12:01PM +0100, Francis Dupont wrote:
In your previous mail you wrote:
People, get real. This policy sucks big time. Change it if you cant't live with people not accepting it.
=> sorry but the last call on the address architecture document is closed!
Does this sound like an episode from "the hitchhiker's guide to the galaxy" or doesn't it? I don't care, to put it bluntly. If the policy is unnecessarily stupid, people won't accept it, and this should be taken into consideration when creating the policy.
PS: addresses on firewire/i-link/ieee 1394 are *not* 64 bit long (:-)!
Well - that's what people have told me why EUI-64 is used, and not EUI-48 with /80s on LANs (which would make perfect sense for Ethernet-alike multiaccess networks). 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
=> sorry but the last call on the address architecture document is closed! Does this sound like an episode from "the hitchhiker's guide to the galaxy" or doesn't it? I don't care, to put it bluntly. If the policy is unnecessarily stupid, people won't accept it, and this should be taken into consideration when creating the policy.
please remember, i keep begging ops folk to get constructively involved in the relevant ietf wgs. randy
Hi, On Thu, Feb 13, 2003 at 07:38:29AM -0800, Randy Bush wrote:
please remember, i keep begging ops folk to get constructively involved in the relevant ietf wgs.
I am following the v6ops list (to get started). What would be the relevant wg for this discussion? (I admit that I'm not very clueful concerning IETF processes and WGs - it's a matter of travel expenses and time spent, which has to be limited at some point) 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
please remember, i keep begging ops folk to get constructively involved in the relevant ietf wgs. I am following the v6ops list (to get started). What would be the relevant wg for this discussion?
ipv6 wg <http://www.ietf.org/html.charters/ipv6-charter.html> randy
please remember, i keep begging ops folk to get constructively involved in the relevant ietf wgs.
I agree with Randy. I am a relative newcomer to the IETF with San Diego in Dec 2000 being my first. I was scared when I went there the first time and things haven't improved... Heck, I am not that much operationally involved anymore. But I think I still beat most of the people going to the IETF... - kurtis -
I am not that much operationally involved anymore. But I think I still beat most of the people going to the IETF...
if you touch a router once a year, you are in the 1% of the ietf who does. this influences the results on which we all run. existing ops folk in the ietf can often be of help to new ops folk trying to participate, should we have an ops lunch in sf? randy
I am not that much operationally involved anymore. But I think I still beat most of the people going to the IETF...
if you touch a router once a year, you are in the 1% of the ietf who does. this influences the results on which we all run.
existing ops folk in the ietf can often be of help to new ops folk trying to participate, should we have an ops lunch in sf?
That actually sounds like a really good idea. How about Monday to try and have it as early in the week as possible? - kurtis -
That actually sounds like a really good idea. How about Monday to try and have it as early in the week as possible?
i have pencilled in monday lunch. randy
People, get real. This policy sucks big time. Change it if you cant't live with people not accepting it.
=> sorry but the last call on the address architecture document is closed!
Does this sound like an episode from "the hitchhiker's guide to the galaxy" or doesn't it?
I don't care, to put it bluntly. If the policy is unnecessarily stupid, people won't accept it, and this should be taken into consideration when creating the policy.
Part of the problem is that there is way to few people in the IETF with a operator background. People come up with ideas that seem good on paper and on either research or enterprise networks but that don't work that well in a operator environment. This was the realisation that made me start going to IETFs... Join to San Fransisco and let's have beer..:) - kurtis -
In your previous mail you wrote: On Wed, Feb 12, 2003 at 05:09:29PM +0100, Francis Dupont wrote:
In your previous mail you wrote:
We use /124s for tunnels, which avoid the problems from Pekka's draft
=> what is the standard which defines a /124 for a link?
What is the standard that prohibits doing this? => draft-ietf-ipngwg-addr-arch-v3-11.txt which is already adopted and should be published ASAP (and RFC 2373 if you believed only in available RFC).
but there is no need for a /64 here. => there is no choice in the standard: all prefixes on a link are /64s.
Please quote the RFC that *mandates* /64s for all links. As far as I remember, it's a SHOULD for multiaccess links, and voluntary for ptp links. => the address architecture draft (and RFC 2373) uses "are required". This is a MUST and the only discussion about it was whether it should be in the address architecture or spread between the "IPv6 over foo" documents. Regards Francis.Dupont@enst-bretagne.fr
participants (7)
-
Andrius Kasparavicius -
Francis Dupont -
Gert Doering -
Jeroen Massar -
Kurt Erik Lindqvist -
Randy Bush -
Sam.Wilson＠ed.ac.uk