Currently we are in the process of planning our IPv6 addressing schema for our network. We are a service provider with around 20 core routers, and several hundred enterprise customers. These customers currently connect back to our core via a separate VLANs or channelized DS1/DS3/OC-X type interfaces. Thus currently lots of /30 IPv4 blocks. Our address allocation is 2001:1940::/32 Here is our current plan, but we are looking for suggestions from people who have been down this road before. The plan is to break out a /48 for our organization. Then break out the first /64 for loopbacks, and the next /64 for point-to-point connections. The PTP /64 then breaks out further into 1 /80 for core links, and 1 /80 for each of our distribution sites. Within these /80's are individual /112's for PTP links. What this will allow us to do is aggregate each sites PTP connections into /80's within our IGP. Looks something like this. 2001:1940::/48 - TransAria 2001:1940::/64 - Loopbacks/NMS/ETC 2001:1940::1/128 - Router 1 2001:1940::2/128 - Router 2 2001:1940:0:1::/64 - PTP Links 2001:1940:1::/80 - Core Links (non-aggergratable) 2001:1940:0:1::/112 - Core Link 1 2001:1940:0:1::1 - Router A 2001:1940:0:1::2 - Router B 2001:1940:0:1::1:1/112 - Core Link 2 2001:1940:0:1::1:1 - Router A 2001:1940:0:1::1:2 - Router B 2001:1940:0:1:1::/80 - Distribution Site 1 2001:1940:0:1:1::/112 - Customer Link 1 2001:1940:0:1:1::1 - Dist Router 2001:1940:0:1:1::2 - Customer Equipment 2001:1940:0:1:1:0:1:0/112 - Customer Link 2 2001:1940:0:1:1:0:1:1 - Dist Router 2001:1940:0:1:1:0:1:2 - Customer Equipment 2001:1940:0:1:2::/80 - Distribution Site 2 2001:1940:0:1:2:::/112 - Customer Link 1 2001:1940:0:1:2::1 - Dist Router 2001:1940:0:1:2::2 - Customer Equipment 2001:1940:0:1:2:0:1:0/112 2001:1940:0:1:2:0:1:1 - Dist Router 2001:1940:0:1:2:0:1:1 - Customer Equipment 2001:1940:1::/48 - Customer 1 Assignment 2001:1940:2::/48 - Customer 2 Assignment 2001:1940:3::/48 - Customer 3 Assignment Thoughts? Thanks! Cody
On 9-aug-2005, at 19:24, Cody Lerum wrote:
Here is our current plan, but we are looking for suggestions from people who have been down this road before. The plan is to break out a /48 for our organization. Then break out the first /64 for loopbacks, and the next /64 for point-to-point connections. The PTP /64 then breaks out further into 1 /80 for core links, and 1 /80 for each of our distribution sites. Within these /80's are individual /112's for PTP links. What this will allow us to do is aggregate each sites PTP connections into /80's within our IGP.
Hm, I would keep the first /48 apart for your own services. Addresses in that first /64 are nice and short. Then a /48 for the routers. You only need /128s for the loopbacks of course, but you may not even need IPv6 loopbacks if you only have iBGP sessions between the IPv4 loopbacks and also exchange IPv6 BGP routes over those. (This does create a dependency on IPv4 for IPv6, but it saves you a lot of BGP sessions.) If you use /64s for router links, you can use eui-64 addressing within those, which has the advantage that you don't have to keep track of which router has the ...1 and which router has the ...2 address. If you use a lot of vlans in your own network (as opposed to customer links) you may also want to endcode the vlan id in bits 48 - 63. Makes everything really simple to debug! I generally like to use a /48 per customer and a separate /64 out of a dedicated /48 for the link to the customer to avoid breaking up their /48 or having to do other hard to remember tricks.
hi this is a very interesting topic
On 9-aug-2005, at 19:24, Cody Lerum wrote:
Here is our current plan, but we are looking for suggestions from people who have been down this road before. The plan is to break out a /48 for our organization. Then break out the first /64 for loopbacks, and the next /64 for point-to-point connections. The PTP /64 then breaks out further into 1 /80 for core links, and 1 /80 for each of our distribution sites. Within these /80's are individual /112's for PTP links. What this will allow us to do is aggregate each sites PTP connections into /80's within our IGP.
Hm, I would keep the first /48 apart for your own services. Addresses in that first /64 are nice and short.
agree. i would keep the first "several" /48s though, in case your network grows. what we do is we don't use anything greater than a /64. (excluding loopbacks) main reason is because it becomes too much of a hassle to keep track of any prefixs greater than that. the first few /48 blocks are reserved for own services and networks and data centers. within these /48s we divide them into /56s and define what they mean example: 2001:db8:a::/48 data center "a" 2001:db8:a::/56 routers, ptp links etc 2001:db8:a:0100::/56 ntp's dns's, etc. 2001:db8:a:0200::/56 hosted streaming servers 2001:db8:a:0300::/56 hosted web servers and so on we did this because its easier to notice problems this way. when an alarm is detected on our NMS at 2001:db8:a:0200::/56 we know right away that there is a problem at the streaming zone. our main business is being an ISP for consumers, so this might differ if you mainly serve corporate customers.
If you use /64s for router links, you can use eui-64 addressing within those, which has the advantage that you don't have to keep track of which router has the ...1 and which router has the ...2 address. If you use a lot of vlans in your own network (as opposed to customer links) you may also want to endcode the vlan id in bits 48 - 63. Makes everything really simple to debug!
i think this is the most important thing in deploying IPv6 networks. make it simple to debug, and that will make life a whole lot easier. --- seiichi
on this side of the puddles, i think most folk use /126s for p2p links. this has been endlessly and loudly debated, but it still seems extremely strange to use 18,446,744,073,709,551,616 addresses for a p2p link. randy
On Tue, 9 August 2005 14:54:39 -1000, Randy Bush wrote:
on this side of the puddles, i think most folk use /126s for p2p links.
I like /124 a lot. No need to argue, I think, but you can apply it both on small Ethernet links as well as on p-t-p links to customers over POS - one linknet size mostly fits it all, especially if the customer wants some 5 to 10 hosts only and play with it. /127 on POS links is no good... Also I cannot help but like how it can be organised with a brain that still works on IPv4 or so. 2^4 is 16, so ::zzx0 up to ::zzxf and, yeah, the next linknet is then ::zzy0 to ::zzyf, with y being just x+1. It just seems strange that when establishing POS links with an all- native v6 providers they won't do it as it *has* to be /64. I hate this whole discussion just universally by now. Anyway, maybe someone could use that in any way. /124 may be nice in some aspects. Alexander
koch@tiscali.net (Alexander Koch) wrote: [/124]
Also I cannot help but like how it can be organised with a brain that still works on IPv4 or so. 2^4 is 16, so ::zzx0 up to ::zzxf and, yeah, the next linknet is then ::zzy0 to ::zzyf, with y being just x+1.
I second that. I get thoroughly confused every time, there's an xxxa coming up after a xxx9. I tend to use xx10 first, then see that it doesn't work, then remember. Currently we're using /126s on p2p, but I believe a migration would be in order, considering the small amount of addresses we are using anyway. I definitely abstain from /64s. This is wasteful. Yours, Elmi. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---
On 10-aug-2005, at 2:54, Randy Bush wrote:
on this side of the puddles, i think most folk use /126s for p2p links. this has been endlessly and loudly debated, but it still seems extremely strange to use 18,446,744,073,709,551,616 addresses for a p2p link.
Well, if you want to be really environmentally conscious, do away with that /126 too and just use link-locals, with a single global address per router for management and the generation of ICMPs.
On Wed, 10 Aug 2005, Iljitsch van Beijnum wrote:
On 10-aug-2005, at 2:54, Randy Bush wrote:
on this side of the puddles, i think most folk use /126s for p2p links. this has been endlessly and loudly debated, but it still seems extremely strange to use 18,446,744,073,709,551,616 addresses for a p2p link.
Well, if you want to be really environmentally conscious, do away with that /126 too and just use link-locals, with a single global address per router for management and the generation of ICMPs.
and you ping the customer links how? (or did I miss the point of the link-locals?)
On 10-aug-2005, at 15:06, Christopher L. Morrow wrote:
Well, if you want to be really environmentally conscious, do away with that /126 too and just use link-locals, with a single global address per router for management and the generation of ICMPs.
and you ping the customer links how? (or did I miss the point of the link-locals?)
You don't. I don't think the point of link-locals has much to do with pinging customers... But since IPv6 routing protocols work over link- locals you don't need global addresses. If you want to ping your customers you should probably use a /126 so they can only use the specific address you give them. You need that anyway if you want to route a /48 or what have you to them. BTW, there is discussion about rethinking /48s for customers in IPv6. Thoughts?
If you want to ping your customers you should probably use a /126 so they can only use the specific address you give them. You need that anyway if you want to route a /48 or what have you to them.
Having just done an IPv6 rollout, I went for a block of addresses which I would use just for p2p links, split it into chunks for peers, customers etc, then used a /126 for each link. Seems to work fine and (I think) seems to be what most people are doing.
BTW, there is discussion about rethinking /48s for customers in IPv6. Thoughts?
The current recommendation for a /48 for any customer (pretty much) does initially seem to me to be a bit wasteful, though that's perhaps because I keep thinking in IPv4 terms. Having said that, I think that perhaps a /48 for home users isn't _really_ necessary. How many domestic appliances can you connect to the net :) StewartB -- Stewart Bamford (Posting as an individual) Level3 Snr IP Engineer *** Views expressed are my own and not necessarily those of Level3 *** Personal website http://www.stewartb.com/
In a message written on Wed, Aug 10, 2005 at 03:55:32PM +0100, sdb@stewartb.com wrote:
The current recommendation for a /48 for any customer (pretty much) does initially seem to me to be a bit wasteful, though that's perhaps because I keep thinking in IPv4 terms. Having said that, I think that perhaps a /48 for home users isn't _really_ necessary. How many domestic appliances can you connect to the net :)
That's not really the question you want to be asking. The current mantra is a /64 per subnet. Now, we can argue that point separately, but taking that as a given for now (so autoconfiguration will work) what a /48 is really telling you is that a home user gets 65536 subnets. IPv6 allocations in the host portion (with /64 boundaries) are sparce, even for the largest networks. The number of hosts becomes unimportant. The question we need to ask is how many independant subnets will they need. This is why many people are proposing a /56 for home users, as it gives you 256 subnets. Still more than most people will need. Others have proposed /52 and /60, since many want to claim DNS is easier if done in nibbles. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
On 10-aug-2005, at 18:03, Leo Bicknell wrote:
IPv6 allocations in the host portion (with /64 boundaries) are sparce, even for the largest networks. The number of hosts becomes unimportant. The question we need to ask is how many independant subnets will they need.
This is why many people are proposing a /56 for home users, as it gives you 256 subnets. Still more than most people will need.
Others have proposed /52 and /60, since many want to claim DNS is easier if done in nibbles.
And the extra precision offered by the intermediate values isn't really required at this point in the discussion. :-) I'm very much oppossed to /56 because it's still more than most users need. In and of itself that doesn't matter, but it's also less than what some users need. This creates the situation where people try to make do with a /56, find out that they need a /48 after all (all those /64 ptps...) and have to renumber. I.e., /56 provides too much potential for shooting yourself in the foot. I think we should go for /60 for (presumably) one-router networks. That's still 3 to 5 times as many subnets as most of those will need. Anyone else should get a /48.
I'm very much oppossed to /56 because it's still more than most users need. In and of itself that doesn't matter, but it's also less than what some users need. This creates the situation where people try to make do with a /56, find out that they need a /48 after all (all those /64 ptps...) and have to renumber. I.e., /56 provides too much potential for shooting yourself in the foot.
ah... so is there the admission that renumbering in IPv6 is pretty much a myth? --bill
On 10-aug-2005, at 18:48, bmanning@vacation.karoshi.com wrote:
This creates the situation where people try to make do with a /56, find out that they need a /48 after all (all those /64 ptps...) and have to renumber.
ah... so is there the admission that renumbering in IPv6 is pretty much a myth?
Renumbering hosts in IPv6 is a breeze. You just change some settings in the routers and the rest happens automatically. It's more renumbering information in the DNS and filters and such that's a problem, regardless of IP version.
On Wed, Aug 10, 2005 at 06:54:10PM +0200, Iljitsch van Beijnum wrote:
On 10-aug-2005, at 18:48, bmanning@vacation.karoshi.com wrote:
This creates the situation where people try to make do with a /56, find out that they need a /48 after all (all those /64 ptps...) and have to renumber.
ah... so is there the admission that renumbering in IPv6 is pretty much a myth?
Renumbering hosts in IPv6 is a breeze. You just change some settings in the routers and the rest happens automatically.
It's more renumbering information in the DNS and filters and such that's a problem, regardless of IP version.
so renumbering out of a /56 into a /48 is harder than renumbering out of a /124 into a /112 how? renumbering - regardless of version is hard... primarly becuase application developers insist that the IP address is the nodes persistant identifier, not where it is in the routing topology. renumbering hosts is a breese in either version of predominate IP protocol, DHCP is your friend. Or if you want less robust functionality and semantic overload, you can use the RA/ND stuff in IPv6. - regardless, renumbering from one address range to another is painful - CIDR -might- be helpful, but artifical constraints e.g /64 only serve to confuse. --bill (ex chair of the IETF PIER wg)
On 10-aug-2005, at 19:32, bmanning@vacation.karoshi.com wrote:
so renumbering out of a /56 into a /48 is harder than renumbering out of a /124 into a /112 how?
Having a /60 or a /48 is better than a /56 or a /48 because: 1. Most people who are going to encounter the problem realize that a / 60 isn't enough and go for the /48 immediately 2. Going from a /60 to a /48 would happen earlier than from a /56 to a /48 so there is less to renumber.
renumbering - regardless of version is hard...
Not hard, inconvenient.
primarly becuase application developers insist that the IP address is the nodes persistant identifier,
Disagree. There are two issues: the DNS and access restrictions and similar based on IP addresses. The DNS can be fixed with some searching and replacing and/or dynamic DNS updates, but using literal IP addresses, especially in filters and such, isn't easy to solve because there are no reasonable alternatives in many cases.
renumbering hosts is a breese in either version of predominate IP protocol, DHCP is your friend.
That friend will kill all your sessions when you get a new address. DHCP implementations in IPv6 aren't ready for prime time either.
Or if you want less robust functionality and semantic overload, you can use the RA/ND stuff in IPv6.
How is that less robust and does it imply a semantic overload?
- regardless, renumbering from one address range to another is painful - CIDR -might- be helpful, but artifical constraints e.g /64 only serve to confuse.
I agree. All boundaries between different parts of the address must be flexible. That includes the boundary at the end of the address. But I guess we have to save something for IPv7.
On Wed, Aug 10, 2005 at 09:26:08PM +0200, Iljitsch van Beijnum wrote:
On 10-aug-2005, at 19:32, bmanning@vacation.karoshi.com wrote:
so renumbering out of a /56 into a /48 is harder than renumbering out of a /124 into a /112 how?
Having a /60 or a /48 is better than a /56 or a /48 because:
we are not talking better/worse, we are talking the issues with renumbering... and the only credible argument you make is...
1. Most people who are going to encounter the problem realize that a / 60 isn't enough and go for the /48 immediately 2. Going from a /60 to a /48 would happen earlier than from a /56 to a /48 so there is less to renumber.
less to renumber. which argues that folks should be given just the amount of space they need, not more. right? :)
renumbering - regardless of version is hard...
Not hard, inconvenient.
inconvient/hard ... regardless of versioning (v4 or v6) it is not trival to renumber a network that is managable.
primarly becuase application developers insist that the IP address is the nodes persistant identifier,
Disagree. There are two issues: the DNS and access restrictions and similar based on IP addresses. The DNS can be fixed with some searching and replacing and/or dynamic DNS updates, but using literal IP addresses, especially in filters and such, isn't easy to solve because there are no reasonable alternatives in many cases.
ok, you disagree. clearly we do not have the same understanding of global networks, end-system configuration and maintaince, and the demand for reliable, auditable logs.
renumbering hosts is a breese in either version of predominate IP protocol, DHCP is your friend.
That friend will kill all your sessions when you get a new address.
Sniff. Tear. your DOA w/ IPv6 as well and IPv4 in a renumbering event. You want to maintain session awareness over a renumbering event? IPv6 is not going to help. You need HIP.
DHCP implementations in IPv6 aren't ready for prime time either.
that statement could be made of so many applications.
Or if you want less robust functionality and semantic overload, you can use the RA/ND stuff in IPv6.
How is that less robust and does it imply a semantic overload?
DHCP is a protocol that has a long interoperability history. RA/ND does not. DHCP has many fine host configuration features .. some of which are being added to the RA/ND suite. Hence my claim of less robust. Semantic overload... hum... I want my router to route. infrastructure services should come from service boxes... in much the same way i want the police to direct traffic, not do my produce shopping, then take the goods home and prepare my meals. The police should do police work, routers should route. YMMV of course. Some people LIKE running their router, RA/ND, DHCP, and DNS, NTP, and WEB server off a single platform. Or due to cost constraints they "bundle-up"... I'm of the opinion that functional seperation is a good thing in the provisioning of network services.
- regardless, renumbering from one address range to another is painful - CIDR -might- be helpful, but artifical constraints e.g /64 only serve to confuse.
I agree. All boundaries between different parts of the address must be flexible. That includes the boundary at the end of the address. But I guess we have to save something for IPv7.
IPv7, IPv8, and IPv9 are all registered w/ the IANA. then IPX is a Novell trademark so i think the next step would have to be IPv11.. --bill
it is not trival to renumber a network that is managable.
this is the key point, e.g. why autoconf is useless in the real ops world. until interfaces have long-lived identities other than their ip addresses, real networks will bind to real ip addresses which must propagate far enough to get to very remote management stations and aggregators. systems where dynamic assignment is pushed from a database, e.g. dhcp, which can be accessed from the management system are just starting to being used. the rest of the real managed world is still static. those are the only two games in the managed town, of which i am aware. the rest of the brilliant ideas are managable-ops-clue-free fantasies, propaganda, or both. e.g. auto-conf is a non-starter except on a small home network. link local is a non-starter. ... randy
In article <1B11954B-DF25-458E-B2A7-E3A5FCBEC74E@muada.com> you write:
On 10-aug-2005, at 18:03, Leo Bicknell wrote:
IPv6 allocations in the host portion (with /64 boundaries) are sparce, even for the largest networks. The number of hosts becomes unimportant. The question we need to ask is how many independant subnets will they need.
This is why many people are proposing a /56 for home users, as it gives you 256 subnets. Still more than most people will need.
Others have proposed /52 and /60, since many want to claim DNS is easier if done in nibbles.
And the extra precision offered by the intermediate values isn't really required at this point in the discussion. :-)
I'm very much oppossed to /56 because it's still more than most users need. In and of itself that doesn't matter, but it's also less than what some users need. This creates the situation where people try to make do with a /56, find out that they need a /48 after all (all those /64 ptps...) and have to renumber. I.e., /56 provides too much potential for shooting yourself in the foot.
So they need to renumber. This really should not be a big deal. IPv6 nodes should all support multiple prefixes, unlike the IPv4 world, so they should be able to transition gracefully from one prefix to the next. Add the new address to the DNS, withdraw the old one after a short period. Similarly for PTR records. With DNAME they don't even need to update the PTR's. The routers just need to add new DNAME records. This still leaves firewall and other products which use raw IPv6 addresses. However if the vendors of these products were to go through the exercise of renumbering I'm sure the most/all of the gotchas would disappear.
I think we should go for /60 for (presumably) one-router networks. That's still 3 to 5 times as many subnets as most of those will need. Anyone else should get a /48.
At 09:46 AM 8/10/2005, Iljitsch van Beijnum wrote:
On 10-aug-2005, at 15:06, Christopher L. Morrow wrote:
Well, if you want to be really environmentally conscious, do away with that /126 too and just use link-locals, with a single global address per router for management and the generation of ICMPs.
and you ping the customer links how? (or did I miss the point of the link-locals?)
You don't. I don't think the point of link-locals has much to do with pinging customers... But since IPv6 routing protocols work over link- locals you don't need global addresses.
If you want to ping your customers you should probably use a /126 so they can only use the specific address you give them. You need that anyway if you want to route a /48 or what have you to them.
BTW, there is discussion about rethinking /48s for customers in IPv6. Thoughts?
Where is this being discussed? What sizing is being discussed? I'm expecting in the long run some ISPs will hand out /128s in the hope that this will once and for all keep customers from putting more than one device on a connection (of course that would be followed immediately by implementations of NATv6 if it happened). There is a draft pending in the IETF V6OPS WG (draft-ietf-v6ops-nap-01.txt) that relies heavily on the fact that everyone and his dog gets a /48 to justify the reasons IPv6 solves the world's problems that were previously solved to varying extents by NAT boxes. If the /48 thing is being discussed somewhere, that would significantly alter the underpinnings of the draft's arguments. Dan
In a message written on Wed, Aug 10, 2005 at 01:51:41PM -0400, Daniel Senie wrote:
Where is this being discussed? What sizing is being discussed? I'm expecting in the long run some ISPs will hand out /128s in the hope that this will once and for all keep customers from putting more than one device on a connection (of course that would be followed immediately by implementations of NATv6 if it happened).
This is a topic of heated discussion at the various RIR meetings, ARIN for most people on this list. Note the next ARIN meeting is with a Nanog, so you might want to stick around (show up early?). In an attempt to be objective, I'll say that there is a line in the sand between the IETF and the RIR's, and right now both groups seem to think the other is stepping over the line, and making the wrong decisions. The IETF seems to think /48 is good, thinks it's extremely unlikely we'll ever run out of space, and considers that if we do in 50 years it's probably ok, time for a new protocol anyway. The RIR's seem to think smaller (/56? /64? /96?) prefixes are good, that we will run out of space under the current plan it's simply a question of when, that deploying a new protocol in 50 years is a bad idea if we can avoid it, and with sane policies we can. Add in operators and their various opinions of NAT, how many addresses a user should get, if auto configuration is good bad or ugly, if you still need DHCP with auto configuration and soforth and you have quite a mess with no group clearly "leading in the polls". -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
There is a draft pending in the IETF V6OPS WG (draft-ietf-v6ops-nap-01.txt) that relies heavily on the fact that everyone and his dog gets a /48 to justify the reasons IPv6 solves the world's problems that were previously solved to varying extents by NAT boxes. If the /48 thing is being discussed somewhere, that would significantly alter the underpinnings of the draft's arguments.
interesting that, after all the cycles of getting the ivtf to stay the <bleep> out of policy, this is happening yet again. the ivtf needs to wake up and smell the coffee, or become even more irrelevant. people are giving out prefixes as needed, not just the religious /48. randy
On Aug 10, 2005, at 11:36 AM, Iljitsch van Beijnum wrote:
On 10-aug-2005, at 20:13, Randy Bush wrote:
the ivtf ?
"Internet Vendor Task Force" -- Randy's term for the IETF.
people are giving out prefixes as needed, not just the religious /48. Yes, and ISPs have historically done so well determining what people "need".
The ISPs have apparently done well in determining what people will pay for. At least those that still exist.
Power to the people.
One of the nice things about IPv4 was that pretty much nobody cared about it other than the folks who were trying to get things working. "The people" who were specifying the protocol were also the folks who were running the network. But that's the past... Rgds, -drc
On 10-aug-2005, at 22:04, David Conrad wrote:
the ivtf
?
"Internet Vendor Task Force" -- Randy's term for the IETF.
:-) I was in the session where Randy threw his final fit as AD. Good times...
people are giving out prefixes as needed, not just the religious /48.
Yes, and ISPs have historically done so well determining what people "need".
The ISPs have apparently done well in determining what people will pay for. At least those that still exist.
There is not enough choice and/or information for the capitalist system to work its magic here.
Power to the people.
One of the nice things about IPv4 was that pretty much nobody cared about it other than the folks who were trying to get things working. "The people" who were specifying the protocol were also the folks who were running the network.
That's exactly the reason why the IETF has such a hard time moving forward: whatever way of abusing IP you can think of, someone is doing it today, and breaking that "feature" will gravely upset them. It's the age old battle between the irresistible force (progress) and the immovable object (users) I guess.
Iljitsch> That's exactly the reason why the IETF has such a hard Iljitsch> time moving forward: whatever way of abusing IP you can Iljitsch> think of, someone is doing it today, and breaking that Iljitsch> "feature" will gravely upset them. It's the age old Iljitsch> battle between the irresistible force (progress) and the Iljitsch> immovable object (users) I guess. And on that vein perhaps it's prudent for people using network prefixes longer than /64 to take care to ensure that the bit positions in the IPv6 address that should correspond to the u and g bits in the modified EUI-64 interface ID (according to RFC 3513) are both set to zero. -roy
Roy Badami wrote:
And on that vein perhaps it's prudent for people using network prefixes longer than /64 to take care to ensure that the bit positions in the IPv6 address that should correspond to the u and g bits in the modified EUI-64 interface ID (according to RFC 3513) are both set to
Is there any known use for those bits? - Kevin
Kevin> Is there any known use for those bits? Not that I know of, but it seems dangerous to assume there never will be, and it's easy to avoid... -roy
On 11-aug-2005, at 2:23, Kevin Loch wrote:
And on that vein perhaps it's prudent for people using network prefixes longer than /64 to take care to ensure that the bit positions in the IPv6 address that should correspond to the u and g bits in the modified EUI-64 interface ID (according to RFC 3513) are both set to
Is there any known use for those bits?
The universal/local bit is copied from the EUI-64/MAC address and flipped, and indicates whether the address is derived from something (supposedly) globally unique or not. Both occur frequently, non- unique stem from manual configuration or RFC 3041 temporary/privacy addresses. The group bit isn't relevant, although you won't see MAC- derived addresses with this bit set, of course. There is no real reason to preserve these bits when the prefix length is > 64.
On Aug 10, 2005, at 3:22 PM, Iljitsch van Beijnum wrote:
The ISPs have apparently done well in determining what people will pay for. At least those that still exist. There is not enough choice and/or information for the capitalist system to work its magic here.
An amusing aspect of markets is that unless there is government involvement, they tend to ignore philosophy and philosophers, resulting in what many may consider sub-optimal decisions (e.g., "reality tv", vhs over beta, and the wide acceptance of NAT). Unfortunately, it is hard to argue with success (although "what are they thinking??" is frequently generated). I am not arguing that the markets are always correct, rather that reality does frequently intrude on the ivory tower. However, to try to not go too far into economic theory, I would suggest that for good or ill, the folks working at/with/for ISPs have a far better understanding of what will keep their businesses afloat than the non-ISP related individuals in the IPv6 working groups. Unless the IPv6 working group can provide a clear and relevant model as to why any particular address partitioning would be better than another in a way that will positively affect the ISP's bottom line, I suspect it will take some Darwinian-like evolution (instead of IPv6 driven "intelligent design") to occur for a consensus to be reached on best common practices for IPv6 addressing.
That's exactly the reason why the IETF has such a hard time moving forward: whatever way of abusing IP you can think of, someone is doing it today, and breaking that "feature" will gravely upset them. It's the age old battle between the irresistible force (progress) and the immovable object (users) I guess.
One person's progress is often another person's waste of time. In my experience, users are actually quite easy to move as long as you give them real justification instead of FUD and/or marketing hype. They are, however, very gun shy. Rgds, -drc
On 10-aug-2005, at 19:51, Daniel Senie wrote:
BTW, there is discussion about rethinking /48s for customers in IPv6. Thoughts?
Where is this being discussed?
All over the place. IETF IPv6 wg, RIRs...
What sizing is being discussed?
The observation is that with the 80% HD ratio (= waste 1 bit in 5 because of administative boundaries in the addressing hierarchy) and a /48 per customer we'll get awfully close to using up 128 bits several decades from now. (3 bits are given for the global unicast space, 80 for the customer = 45, 80% = 36 bits ~= 64 billion /48s for some 10 billion people. Not immediately problematic, but a few more bits margin just in case wouldn't be a bad idea.) So we can change the HD ratio, change the /48 or change the /64. IETF will 99% sure veto changing /64 because it's in a lot of RFCs and implementations, so that leaves increasing the HD ratio or rethinking giving _every_ customer a /48.
I'm expecting in the long run some ISPs will hand out /128s in the hope that this will once and for all keep customers from putting more than one device on a connection
That only makes sense if they can give out more /128s on demand for a price to make more money. But I don't see it happening anyway.
(of course that would be followed immediately by implementations of NATv6 if it happened).
Yeah right, the whole industry is going to spend man-years just because one ISP does something weird? (Don't underestimate the crap that goes on below the surface to make NAT work for stuff that isn't simple TCP/client-server.)
There is a draft pending in the IETF V6OPS WG (draft-ietf-v6ops- nap-01.txt) that relies heavily on the fact that everyone and his dog gets a /48
A quick scan doesn't show this.
On Tue, 9 Aug 2005, Randy Bush wrote:
on this side of the puddles, i think most folk use /126s for p2p links. this has been endlessly and loudly debated, but it still seems extremely strange to use 18,446,744,073,709,551,616 addresses for a p2p link.
jumping in late :) with less than I'd like of v6 experience :) I think the debate goes something like: "use /64 cause autoconf works!" (and it's in the spec as 'lan' links get /64's) and the other half is your debate of 18 million billion addrs for a ptp sonet link is craziness (and wasteful) and /126's work fine since we never autoconf things we are going to ping monitor. -chris
participants (15)
-
Alexander Koch -
bmanning＠vacation.karoshi.com -
Christopher L. Morrow -
Cody Lerum -
Daniel Senie -
David Conrad -
Elmar K. Bins -
Iljitsch van Beijnum -
kawamura seiichi -
Kevin Loch -
Leo Bicknell -
Mark Andrews -
Randy Bush -
Roy Badami -
sdb＠stewartb.com