Re: ISP customer assignments
The address space is daunting in scale as you have noted, but I don't see any lessons learned in address allocation between IPv6 and IPv4. Consider as a residential customer, I will be provided a /64, which means each individual on Earth will have roughly 1 billion addresses each. Organizations will be provided /48s or smaller, but given the current issues with routing /48's globally, I think you will find more organizations fighting for /32s or smaller... so what once was a astonomical number of addresses that one cannot concieve numerically, soon becomes much smaller. I can see an IPv7 in the future, and doing it all over again... I just hope I retire before it comes... The only difference I can see between IPv4 and IPv6 is how much of a pain it is to type a 128 bit address... Just like back in the day when Class B networks were handed out like candy, one day we will be figuring out how to put in emergency allocations on the ARIN listserv for IPv6 because of address exhaustion and waste. Food for thought...
Message: 3 Date: Mon, 5 Oct 2009 17:47:12 -0400 From: Dorn Hetzel <dhetzel@gmail.com> Subject: Re: ISP customer assignments To: bmanning@vacation.karoshi.com Cc: NANOG list <nanog@nanog.org> Message-ID: <7db2dcf90910051447r5bd7e42fja0b750dceb8d764@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1
The estimated mass of our galaxy is around 6x10^42Kg. The mass of earth is a little less than 6x10^24Kg.
2^128 is around 3.4x10^38. So in a flat address space we have about one IPV6 address for every 20,000Kg in the galaxy or for every 20 picograms in the earth...
One would hope it would last for a while :)
On Mon, Oct 5, 2009 at 5:32 PM, <bmanning@vacation.karoshi.com> wrote:
considered top posting to irritate a few folks, decided not to.
On Mon, Oct 05, 2009 at 04:20:44PM -0500, Chris Owen wrote:
On Oct 5, 2009, at 1:43 PM, Wayne E. Bouchard wrote:
Whenever you declare something to be "inexhasutable" all you do is increase demand. Eventually you reach a point where you realize that there is, in fact, a limit to the inexhaustable resource.
This is where I think there is a major disconnect on IPv6. The size of the pool is just so large that people just can't wrap their heads around it.
2^128 is enough space for every man, woman and child on the planet to have around 4 billion /64s to themselves. Even if we assume
everyone
might possibly need say 10 /64s per person that still means we are covered until the population hits around 2,600,000,000,000,000,000.
Chris
here, you expose a hidebound bias to 20th century networking. please remember that - with few exceptions - people network at a very different level than machines. people don't need IP addresses - computing nodes that want to communicate do.
Just for grins, put a unique IPv6 address in every active RFID tag. ... and remember that there are RFID printers that can put 18 tags on a single A4 sheet. Numbers will become disposible, like starbucks coffee cups and MCD's bigmac containers.
--bill
On 10/05/2009 04:41 PM, Robert.E.VanOrmer@frb.gov wrote:
The address space is daunting in scale as you have noted, but I don't see any lessons learned in address allocation between IPv6 and IPv4. Consider as a residential customer, I will be provided a /64, which means each individual on Earth will have roughly 1 billion addresses each. Organizations will be provided /48s or smaller, but given the current issues with routing /48's globally, I think you will find more organizations fighting for /32s or smaller... so what once was a astonomical number of addresses that one cannot concieve numerically, soon becomes much smaller. I can see an IPv7 in the future, and doing it all over again... I just hope I retire before it comes... The only difference I can see between IPv4 and IPv6 is how much of a pain it is to type a 128 bit address... Just like back in the day when Class B networks were handed out like candy, one day we will be figuring out how to put in emergency allocations on the ARIN listserv for IPv6 because of address exhaustion and waste.
I'm perplexed. At what size address would people stop worrying about the "finite" address space? 256 bits? 1024 bits? I just don't get it. It's not like people get stressed out about running out of name space in English which is probably more "finite" than ipv6. Mike
On Oct 5, 2009, at 7:50 PM, Michael Thomas wrote:
I'm perplexed. At what size address would people stop worrying about the "finite" address space? 256 bits? 1024 bits?
I just don't get it. It's not like people get stressed out about running out of name space in English which is probably more "finite" than ipv6.
Unless you're trying to find a nice, catchy, short domain name. ;-) But seriously: Many people don't seem to have good intuition about really big numbers. Say, on the order of 2^128. The same thing comes up in discussions about hash collisions in, e.g., content based naming with a 160-bit namespace. I think it's because the numbers are so astronomically big, that without some amount of math and having thought about it with paper and pencil, people automatically scale the #s into terms they can think of as "really big" (like, # of people on earth). So when they think about the 128-bit namespace, they apply intuition that works for a 35-bit namespace... -Dave
On 10/05/2009 04:59 PM, David Andersen wrote:
On Oct 5, 2009, at 7:50 PM, Michael Thomas wrote:
I'm perplexed. At what size address would people stop worrying about the "finite" address space? 256 bits? 1024 bits?
I just don't get it. It's not like people get stressed out about running out of name space in English which is probably more "finite" than ipv6.
Unless you're trying to find a nice, catchy, short domain name. ;-)
But seriously: Many people don't seem to have good intuition about really big numbers. Say, on the order of 2^128. The same thing comes up in discussions about hash collisions in, e.g., content based naming with a 160-bit namespace. I think it's because the numbers are so astronomically big, that without some amount of math and having thought about it with paper and pencil, people automatically scale the #s into terms they can think of as "really big" (like, # of people on earth). So when they think about the 128-bit namespace, they apply intuition that works for a 35-bit namespace...
Hey, that's are why logarithms are our friends :) Seriously though, when i was at that big ol' networking company, the size of the address space was so ridiculously large that hardware and software people charged with implementing it certainly had no love for it. So it's not like vendors were cheaping out or something -- it makes their life quite a bit more, uh, interesting. Ipv6 *is* what what was learned about ipv4 addresses: make the address space so astronomically large that nobody could possibly worry. Curse those logarithms on second thought. Mike
The fallacy here is the idea that IPv6 has a 128-bit namespace. It does not. It has two 64 bit namespaces, where one is expected to be globally unique and flat, While the other is hierarchical. IPv6 has a lot more room than v4 does, but it is worth noting Than in v4, a customer would typically use a single /32. In v6-speak, a /48 is a smaller percentage of the overall space, but it would not be prudent to view the v6-space as infinite. Remember, the value of a network increases with the number of interconnections, and those interconnections are what get numbered. All of the comparisons to atoms in the galaxy or human population are ignoring the hierarchical element of the 64-bit space. The nature of hierarchical allocations requires a Significant "burn" in terms of wasted, unusable addresses. All that said, the /64-based v6 addressing approaches are going to be with us for quite a while, so they're worth getting used to. -David Barak David Andersen wrote:
On Oct 5, 2009, at 7:50 PM, Michael Thomas wrote:
I'm perplexed. At what size address would people stop worrying about the "finite" address space? 256 bits? 1024 bits?
I just don't get it. It's not like people get stressed out about running out of name space in English which is probably more "finite" than ipv6. Unless you're trying to find a nice, catchy, short domain name. ;-) But seriously: Many people don't seem to have good intuition about really big numbers. Say, on the order of 2^128. The same thing comes up in discussions about hash collisions in, e.g., content based naming with a 160-bit namespace. I think it's because the numbers are so astronomically big, that without some amount of math and having thought about it with paper and pencil, people automatically scale the #s into terms they can think of as "really big" (like, # of people on earth). So when they think about the 128-bit namespace, they apply intuition that works for a 35-bit namespace... -Dave
I've been trying to stay out of this discussion because it is pointless, however as I can't help picking at scratching mosquito bites either... On Oct 5, 2009, at 4:50 PM, Michael Thomas wrote:
I'm perplexed. At what size address would people stop worrying about the "finite" address space? 256 bits? 1024 bits?
The issue is that given it is a _finite_ space, its longevity depends exclusively on allocation policy. Since allocation policy is determined by human decision, it is possible (albeit unlikely) that decisions will be made that will result in runout of IPv6 far sooner than one would predict given the vast size of the address space. To wit, we have already had allocations of a /13, /16s, /19s, /20s, etc., irrespective of the fact that the organizations that obtained those prefixes would likely be unable to make a dent in their allocations by the time the sun burned out (assuming they allocate in a rational fashion). Now, as an exercise to the reader, compare how many of those prefixes exist in IPv6 to how many there are in IPv4... Regards, -drc
On Mon, 5 Oct 2009, Robert.E.VanOrmer@frb.gov wrote:
The address space is daunting in scale as you have noted, but I don't see any lessons learned in address allocation between IPv6 and IPv4. Consider
A lesson learned is that thinking about address allocation is something you do not want to spend too many precious seconds of your life on. That's one reason why the space was designed to be so big. Being penny-wise and pound-foolish doesn't really save you much in the IPv6 address space. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony@lava.net
On Mon, Oct 05, 2009, Antonio Querubin wrote:
On Mon, 5 Oct 2009, Robert.E.VanOrmer@frb.gov wrote:
The address space is daunting in scale as you have noted, but I don't see any lessons learned in address allocation between IPv6 and IPv4. Consider
A lesson learned is that thinking about address allocation is something you do not want to spend too many precious seconds of your life on. That's one reason why the space was designed to be so big. Being penny-wise and pound-foolish doesn't really save you much in the IPv6 address space.
.. address aggregation? .. convergence time? I'm sorry, but seeing a good fraction of my local IX simply containing a few ISP's deaggregated view of their "local" internal networks versus a sensible allocation policy makes me cry. IPv6 may just make this worse. IPv6 certainly won't make it "better". adrian
On Mon, Oct 05, 2009, Antonio Querubin wrote:
On Mon, 5 Oct 2009, Robert.E.VanOrmer@frb.gov wrote:
The address space is daunting in scale as you have noted, but I don't see any lessons learned in address allocation between IPv6 and IPv4. Consider
A lesson learned is that thinking about address allocation is something you do not want to spend too many precious seconds of your life on. That's one reason why the space was designed to be so big. Being penny-wise and pound-foolish doesn't really save you much in the IPv6 address space.
.. address aggregation? .. convergence time?
I'm sorry, but seeing a good fraction of my local IX simply containing a few ISP's deaggregated view of their "local" internal networks versus a sensible allocation policy makes me cry. IPv6 may just make this worse. IPv6 certainly won't make it "better".
That would seem to be an IX administrative problem. As it stands, there are lots and lots and lots of AS's that advertise multiple blocks of space. Ideally, one would rather see a large ISP get a single delegation, rather than advertising 50 or 500. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
On Mon, Oct 05, 2009, Joe Greco wrote:
I'm sorry, but seeing a good fraction of my local IX simply containing a few ISP's deaggregated view of their "local" internal networks versus a sensible allocation policy makes me cry. IPv6 may just make this worse. IPv6 certainly won't make it "better".
That would seem to be an IX administrative problem.
Sure, if you don't want to see those local networks. But since the cost of getting from "Perth" to "! Perth" is (was?) a lot higher than what you guys even pay for international transit at non-Cogent rates, we have some sort of desire to keep as much traffic local as possible. Hence "Local only" announcements.
As it stands, there are lots and lots and lots of AS's that advertise multiple blocks of space. Ideally, one would rather see a large ISP get a single delegation, rather than advertising 50 or 500.
.. and what about their customers with portable address space? What if every single customer decides they now want to multihome, dynamic endpoint resolution stuff (LISA?) isn't ready, and companies simply join the RIR and buy their own IP space? :) Adrian
On 10/05/2009 05:09 PM, Adrian Chadd wrote:
On Mon, Oct 05, 2009, Antonio Querubin wrote:
On Mon, 5 Oct 2009, Robert.E.VanOrmer@frb.gov wrote:
The address space is daunting in scale as you have noted, but I don't see any lessons learned in address allocation between IPv6 and IPv4. Consider
A lesson learned is that thinking about address allocation is something you do not want to spend too many precious seconds of your life on. That's one reason why the space was designed to be so big. Being penny-wise and pound-foolish doesn't really save you much in the IPv6 address space.
.. address aggregation? .. convergence time?
I'm sorry, but seeing a good fraction of my local IX simply containing a few ISP's deaggregated view of their "local" internal networks versus a sensible allocation policy makes me cry. IPv6 may just make this worse. IPv6 certainly won't make it "better".
There's a good reason for that: ipv6 isn't intended to do anything about disaggregation. Which as you rightly point out is a problem in ipv4 too. IIRC, there was a contingent who thought that address space and aggregation needed to be considered as a single problem. They lost the argument and hence ipv6 as it is today and the previously unsolved aggregation problem... still unsolved. Mike
The address space is daunting in scale as you have noted, but I don't see any lessons learned in address allocation between IPv6 and IPv4. Consider
A lesson learned is that thinking about address allocation is something you do not want to spend too many precious seconds of your life on. That's one reason why the space was designed to be so big. Being penny-wise and pound-foolish doesn't really save you much in the IPv6 address space.
.. address aggregation? .. convergence time?
I'm sorry, but seeing a good fraction of my local IX simply containing a few ISP's deaggregated view of their "local" internal networks versus a sensible allocation policy makes me cry. IPv6 may just make this worse. IPv6 certainly won't make it "better".
Is someone not making sensible use of their IPv6 allocation? Another one of the goals is to enable organization (and the Internet, prior to PI space) to be far more aggregatable. Real example: Instead of one enterprise network having 31 dis-contiguous IPv4 /16s they could get one (large) IPv6 allocation. ... With room to grow and still aggregate. PI space changes that conversation on the DFZ side back to a bit of a swamp until we get that fixed in one fashion or another ... /TJ
Is someone not making sensible use of their IPv6 allocation? Another one of the goals is to enable organization (and the Internet, prior to PI space) to be far more aggregatable. Real example: Instead of one enterprise network having 31 dis-contiguous IPv4 /16s they could get one (large) IPv6 allocation. ... With room to grow and still aggregate.
PI space changes that conversation on the DFZ side back to a bit of a swamp until we get that fixed in one fashion or another ... /TJ
You sure you got the target right? When I look at the the last CIDR report, top-30 would give a 70% improvement in DFZ. Guess how many end users with PI are in that top 30? Tim:>
If people start getting /32s because some ISPs are refusing to route / 48s, then, the RIRs are not doing their stewardship job correctly and we should resolve that issue. If addresses are handed out according to policies, there is more than enough space for every individual to have a /48. I think that /56s for residential customers are probably a good idea and I agree that /48s are usually excessive for residential. (a /64 is far more than a billion addresses since 32 bits if 4 billion and a /64 is whatever number 4 billion^2 works out to, basically 16 followed by lots more digits). As a residential customer, if you get a /64, then, your ISP is really limiting you in ways they should not. You should get at least a /56 in most cases. I think that comparing this to class Bs is kind of absurd, and, I think that the people talking about lessons learned haven't really analyzed the lessons very well. The argument of "lessons learned" usually centers around the idea that we should regard address space as finite and seek ways to maximize its use. The reality is that is not the best lesson. That is what you do when address space is finite and insufficient and you can't make use of extra bits to do other optimizations. Therefore, the best lesson to learn is simply that the IPv4 space was simply not large enough and that we need a much much much larger space with bits available to do other forms of optimization. IPv6 does appear to contain that lesson rather well. We have TONS of bits available on each network for host addressing. So much so that complicated bizarre subnet address calculations and DNS reverse delegation difficulties become a thing of the past (look at the hacks necessary to delegate reverse DNS to 16 different /28 customers in a /24 block, for example). In essence, a class B was equivalent to a /56 in its original form, you could carve it up into 256 /24s. In IPv6, we have plenty of space to issue /56 and even /48 networks to every small to medium business, home, etc. and still have lots left over. Large organizations and IPSs easily get /32s which each contain 65,536 /48s, so, you can divide your multi-national mega-corp into as many as 65,536 regions and give each region a /48 and still be OK. IPv6 offers so much address space that we could give every existing IPv4 user an entire IPv6 ISP allocation (no, I'm not recommending this) and still have enough /32s left over in IPv6 to give one to each ISP and large mega-corp. Lesson learned... The original address was far too small. The new address space is actually large enough that this is a pretty good guess at how to generate addresses that will be fine for decades to come and still have space left over. In fact, so much so, that, to test the theory, we're issuing 1/8th of it this way, and, if it doesn't work out as planned, we can change the allocation policies for the other 7/8ths of the space. So... Lesson learned... If we had tossed classful addressing overboard in IPv4 when we allocated 1/8th of the address space, most of the legacy /8s wouldn't be. Owen On Oct 5, 2009, at 4:41 PM, Robert.E.VanOrmer@frb.gov wrote:
The address space is daunting in scale as you have noted, but I don't see any lessons learned in address allocation between IPv6 and IPv4. Consider as a residential customer, I will be provided a /64, which means each individual on Earth will have roughly 1 billion addresses each. Organizations will be provided /48s or smaller, but given the current issues with routing /48's globally, I think you will find more organizations fighting for /32s or smaller... so what once was a astonomical number of addresses that one cannot concieve numerically, soon becomes much smaller. I can see an IPv7 in the future, and doing it all over again... I just hope I retire before it comes... The only difference I can see between IPv4 and IPv6 is how much of a pain it is to type a 128 bit address... Just like back in the day when Class B networks were handed out like candy, one day we will be figuring out how to put in emergency allocations on the ARIN listserv for IPv6 because of address exhaustion and waste.
Food for thought...
Message: 3 Date: Mon, 5 Oct 2009 17:47:12 -0400 From: Dorn Hetzel <dhetzel@gmail.com> Subject: Re: ISP customer assignments To: bmanning@vacation.karoshi.com Cc: NANOG list <nanog@nanog.org> Message-ID: <7db2dcf90910051447r5bd7e42fja0b750dceb8d764@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1
The estimated mass of our galaxy is around 6x10^42Kg. The mass of earth is a little less than 6x10^24Kg.
2^128 is around 3.4x10^38. So in a flat address space we have about one IPV6 address for every 20,000Kg in the galaxy or for every 20 picograms in the earth...
One would hope it would last for a while :)
On Mon, Oct 5, 2009 at 5:32 PM, <bmanning@vacation.karoshi.com> wrote:
considered top posting to irritate a few folks, decided not to.
On Mon, Oct 05, 2009 at 04:20:44PM -0500, Chris Owen wrote:
On Oct 5, 2009, at 1:43 PM, Wayne E. Bouchard wrote:
Whenever you declare something to be "inexhasutable" all you do is increase demand. Eventually you reach a point where you realize that there is, in fact, a limit to the inexhaustable resource.
This is where I think there is a major disconnect on IPv6. The size of the pool is just so large that people just can't wrap their heads around it.
2^128 is enough space for every man, woman and child on the planet to have around 4 billion /64s to themselves. Even if we assume
everyone
might possibly need say 10 /64s per person that still means we are covered until the population hits around 2,600,000,000,000,000,000.
Chris
here, you expose a hidebound bias to 20th century networking. please remember that - with few exceptions - people network at a very different level than machines. people don't need IP addresses - computing nodes that want to communicate do.
Just for grins, put a unique IPv6 address in every active RFID tag. ... and remember that there are RFID printers that can put 18 tags on a single A4 sheet. Numbers will become disposible, like starbucks coffee cups and MCD's bigmac containers.
--bill
Owen, On Oct 5, 2009, at 5:05 PM, Owen DeLong wrote:
If people start getting /32s because some ISPs are refusing to route /48s, then, the RIRs are not doing their stewardship job correctly and we should resolve that issue.
Since when do RIRs, good stewards or not, control routing policy of ISPs?
IPv6 offers so much address space that we could give every existing IPv4 user an entire IPv6 ISP allocation (no, I'm not recommending this) and still have enough /32s left over in IPv6 to give one to each ISP and large mega-corp.
Um. How many /32s are their in IPv4? How many /32s are their in IPv6? Regards, -drc
On Oct 5, 2009, at 5:20 PM, David Conrad wrote:
Um. How many /32s are their in IPv4? How many /32s are their in IPv6?
Of course, that should be "there" in both cases. Wow. Regards, -drc
The address space is daunting in scale as you have noted, but I don't see any lessons learned in address allocation between IPv6 and IPv4.
That's probably because IPv4 was a technology where the expected host address allocation strategy was (last+1) and IPv6 is a technology where the default host address allocation strategy involves shooting into an extremely extra-sparse 64-bit address space. These are incredibly different things.
Consider as a residential customer, I will be provided a /64, which means each individual on Earth will have roughly 1 billion addresses each.
Um, no. Unless by "roughly" we use a definition where 1 is roughly equal to 18 billion. Yes, that's right, a /64 is 18 billion *billion*. Generally speaking, we shouldn't *want* end users to be provided with a single /64. The number of addresses is not the point. The idea of getting rid of the horribleness that is CIDR is the point. For example, consider the network 206.55.76.0/23. If I assign that to an Ethernet interface, I have a problem because two addresses in the middle of the network, 206.55.76.255 and 206.55.77.0, are less-than- fully-usable because stupid idiot retards out on the Internet will see that last octet and will firewall it. And by "stupid idiot retards," I don't necessarily mean end users, I mean *VENDORS*. (You know who you are.) The current revision of IPv6 introduces a way to nail down the boundary between network and host. This is fantastic, from an implementation point of view. It simplifies the design of silicon for forwarding engines, etc. And here's the kicker. If it /really/ bothers you, just bear in mind that having another whole 64 bits as the host space means that if ever the V6Internet is in crisis and is running out of IP space, unlike IPv4, we can "fix" that problem by changing the addressing strategy within the local AS.
Organizations will be provided /48s or smaller, but given the current issues with routing /48's globally, I think you will find more organizations fighting for /32s or smaller...
Oh puhhhhhleeeze. Where do we get these newbies from. Part of the reason for forming a group such as NANOG was that there were lots of routing issues; we still see requests for help for that sort of stuff today on the IPv4 Internet. Anyone who remembers the fun days of the early commercial Internet would likely say that we've got it easy today.
so what once was a astonomical number of addresses that one cannot concieve numerically, soon becomes much smaller. I can see an IPv7 in the future, and doing it all over again... I just hope I retire before it comes... The only difference I can see between IPv4 and IPv6 is how much of a pain it is to type a 128 bit address...
You don't do that. Or at least, you shouldn't do that. :-) We have a fairly reliable DNS system these days...
Just like back in the day when Class B networks were handed out like candy, one day we will be figuring out how to put in emergency allocations on the ARIN listserv for IPv6 because of address exhaustion and waste.
Not likely to happen in this century. One of the lessons that *was* learned was that it's better to go too big than too small. People just have a rough time visualizing how massively immense 2^128 actually is. But this discussion is really not relevant to NANOG; if you wish to fight this battle, the people with the clue-by-fours are over on the IPv6 lists.
Food for thought...
Only if by "food" you mean "I went down to Lardburger and ate until I had a heart attack and died." You're not bringing anything new to the table, least of all in the fact department, which is about the only way you could manage to convince people that there's a problem. And the very thing you're complaining about would actually be the obvious safety valve if there's a problem. That immense, extremely sparse space that forms the host portion of an IPv6 address... that is where we dip into in the extremely unlikely event there's a problem. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
On Mon, 05 Oct 2009 20:14:01 -0400, Joe Greco <jgreco@ns.sol.net> wrote:
Generally speaking, we shouldn't *want* end users to be provided with a single /64. The number of addresses is not the point. The idea of getting rid of the horribleness that is CIDR is the point.
You underestimate the power of the marketing department and the bean counters. I assure you, residential ISPs are looking for schemes to give out as little address space as possible.
The current revision of IPv6 introduces a way to nail down the boundary between network and host. This is fantastic, from an implementation point of view. It simplifies the design of silicon for forwarding engines, etc.
And it's 150% Wrong Thinking(tm). IPv6 is classless - PERIOD. The instant some idiot wires /64 into silicon, we're right back to not being able to use x.x.x.0 and x.x.x.255. Addresses are 128-bits; you cannot make any assumptions about what people may or may not be doing with those bits. If I don't use SLAAC, then I'm not bound by it's lame rules.
You don't do that. Or at least, you shouldn't do that. :-) We have a fairly reliable DNS system these days...
And where did DNS get the name/number assignments? In my case, it's either been typed in by ME or automatically updated by DHCP. --Ricky
On 05/10/09 23:23 -0400, Ricky Beam wrote:
You underestimate the power of the marketing department and the bean counters. I assure you, residential ISPs are looking for schemes to give out as little address space as possible.
That has not been my (limited) experience. If you are aware of any ISPs which are not handing out a reasonable address space to customers, please call them out.
The current revision of IPv6 introduces a way to nail down the boundary between network and host. This is fantastic, from an implementation point of view. It simplifies the design of silicon for forwarding engines, etc.
And it's 150% Wrong Thinking(tm). IPv6 is classless - PERIOD. The instant some idiot wires /64 into silicon, we're right back to not being able to use x.x.x.0 and x.x.x.255. Addresses are 128-bits; you cannot make any assumptions about what people may or may not be doing with those bits. If I don't use SLAAC, then I'm not bound by it's lame rules.
You don't do that. Or at least, you shouldn't do that. :-) We have a fairly reliable DNS system these days...
The assumption that IPv6 addresses are harder has not been my experience. A server address of 2610:b8:5::1 is just as easy for me to remember as 67.217.144.1. Granted, auto configured addresses are much harder to remember.
And where did DNS get the name/number assignments? In my case, it's either been typed in by ME or automatically updated by DHCP.
Anything I put in DNS is a server/router, and gets a static address, just like with IPv4. -- Dan White BTC Broadband
On Tue, 6 Oct 2009 09:25:44 -0500 Dan White <dwhite@olp.net> wrote:
On 05/10/09 23:23 -0400, Ricky Beam wrote:
You underestimate the power of the marketing department and the bean counters. I assure you, residential ISPs are looking for schemes to give out as little address space as possible.
That has not been my (limited) experience. If you are aware of any ISPs which are not handing out a reasonable address space to customers, please call them out.
Once one of them actually realises how much address space they've been given, and that giving more perceived value to a customer will win them the business, I think they will e.g. same price, same quota/bandwidth, one ISP giving you 64K more address space. I think customers will say, "I fully understand what it's for, and I don't really know what I'll use it for .. but I'll have it if I ever need it."
The current revision of IPv6 introduces a way to nail down the boundary between network and host. This is fantastic, from an implementation point of view. It simplifies the design of silicon for forwarding engines, etc.
And it's 150% Wrong Thinking(tm). IPv6 is classless - PERIOD. The instant some idiot wires /64 into silicon, we're right back to not being able to use x.x.x.0 and x.x.x.255. Addresses are 128-bits; you cannot make any assumptions about what people may or may not be doing with those bits. If I don't use SLAAC, then I'm not bound by it's lame rules.
I think it is both "classless" and "classfull" (although it's different enough that we probably should stop using loaded IPv4 terms ...) Forwarding is purely "classless" - the best route is the one with the longest matching prefix length, regardless of where that prefix length lands within the 128 bits. For 1/8th of the address space, it's "classful". It's been shown that humans work best with simplicity, so introducing fixed operational (but not forwarding) boundaries between node, subnet and global prefixes makes IPv6 much more operationally simple than dealing with IPv4 classes, subnets or classless addressing. I think anybody who has dealt operationally with IPX, Appletalk, XNS, DECnet or even Ethernet with it's single OUI/Node ID boundary would agree. If the plan for the "classful" 1/8th ends up being wrong, the "classless" forwarding means that we don't have to deploy new routing code or hardware to change to a different addressing model, be it "classless" or something else.
You don't do that. Or at least, you shouldn't do that. :-) We have a fairly reliable DNS system these days...
The assumption that IPv6 addresses are harder has not been my experience. A server address of 2610:b8:5::1 is just as easy for me to remember as 67.217.144.1. Granted, auto configured addresses are much harder to remember.
And where did DNS get the name/number assignments? In my case, it's either been typed in by ME or automatically updated by DHCP.
Anything I put in DNS is a server/router, and gets a static address, just like with IPv4.
-- Dan White BTC Broadband
On Tue, 06 Oct 2009 17:40:40 -0400, Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:
I think it is both "classless" and "classfull" (although it's different enough that we probably should stop using loaded IPv4 terms ...)
It's _classless_. There's none of this Class A, B, C, D, or E nonsense. The word everyone is dancing around is, "hierarchical". How the bits get divided up depends on what you want to do with it. SLAAC, in it's current form, requires a 64-bit prefix, but there are other ways to assign addresses that do not have that requirement. --Ricky
Rick et al, I work at an ISP, and I know staff at several other ISPs, we are all trying to do this right. If a /56 makes sense and is supported by the IPv6 technology and we won't have issues supplying these to customers (technically speaking), then we will most likely do this or something similar. The issue is more of a nuanced issue. There seems to be a variance between "It's OK to just give out a /64" to "You better be thinking about giving out a /48". I can live in those boundaries and am most likely fine with either. I'm leaning toward a /56 for regular subscribers and a /48 only for business or large scale customers, and undecided on dial-up. How does this sound? This wasn't suppose to digress to this level of vitriol. - Brian
-----Original Message----- From: Ricky Beam [mailto:jfbeam@gmail.com] Sent: Monday, October 05, 2009 10:23 PM To: Joe Greco; Robert.E.VanOrmer@frb.gov Cc: nanog@nanog.org Subject: Re: ISP customer assignments
On Mon, 05 Oct 2009 20:14:01 -0400, Joe Greco <jgreco@ns.sol.net> wrote:
Generally speaking, we shouldn't *want* end users to be provided with a single /64. The number of addresses is not the point. The idea of getting rid of the horribleness that is CIDR is the point.
You underestimate the power of the marketing department and the bean counters. I assure you, residential ISPs are looking for schemes to give out as little address space as possible.
The current revision of IPv6 introduces a way to nail down the boundary between network and host. This is fantastic, from an implementation point of view. It simplifies the design of silicon for forwarding engines, etc.
And it's 150% Wrong Thinking(tm). IPv6 is classless - PERIOD. The instant some idiot wires /64 into silicon, we're right back to not being able to use x.x.x.0 and x.x.x.255. Addresses are 128-bits; you cannot make any assumptions about what people may or may not be doing with those bits. If I don't use SLAAC, then I'm not bound by it's lame rules.
You don't do that. Or at least, you shouldn't do that. :-) We have a fairly reliable DNS system these days...
And where did DNS get the name/number assignments? In my case, it's either been typed in by ME or automatically updated by DHCP.
--Ricky
There seems to be a variance between "It's OK to just give out a /64" to "You better be thinking about giving out a /48". I can live in those boundaries and am most likely fine with either. I'm leaning toward a /56 for regular subscribers and a /48 only for business or large scale customers, and undecided on dial-up. How does this sound?
The starting point is to give everybody a /48 per site. If a business customer has 3 sites, then give them enough space for a /48 for each site. Could be 3 /48s or could be a /46. But, if you have a lot of residential customers, it is quite reasonable to give them a /56 per site instead. Be prepared for some customers to ask for two /56s because they have a granny-flat or in-law apartment in the house. Also be prepared for some to ask for a /48 because they are running a business at home, or they are technical types who have a their own home network lab. Your plan for /56 to residential subscribers and /48 to business subscribers sounds perfectly fine as long as your systems have some way to accomodate that grey area, either by recording a /48 against a residential subscriber or counting them as a class of business customer that pays a residential rate. Charging a customer extra for more IPv6 addresses just will not fly in a competitive market. --Michael Dillon
Sorry to be a curmudgeon and let me play devil's advocate for a minute. I realize that the address space is enormous; gigantic, even, but if we treat it as cavalierly as you all are proposing, it will get used up. If its treated like an infinite resource that will never, ever be used up as we have done with every other resource on the planet, won't we find ourselves in a heap of trouble? Curtis Michael Dillon wrote:
There seems to be a variance between "It's OK to just give out a /64" to "You better be thinking about giving out a /48". I can live in those boundaries and am most likely fine with either. I'm leaning toward a /56 for regular subscribers and a /48 only for business or large scale customers, and undecided on dial-up. How does this sound?
The starting point is to give everybody a /48 per site. If a business customer has 3 sites, then give them enough space for a /48 for each site. Could be 3 /48s or could be a /46.
But, if you have a lot of residential customers, it is quite reasonable to give them a /56 per site instead. Be prepared for some customers to ask for two /56s because they have a granny-flat or in-law apartment in the house. Also be prepared for some to ask for a /48 because they are running a business at home, or they are technical types who have a their own home network lab.
Your plan for /56 to residential subscribers and /48 to business subscribers sounds perfectly fine as long as your systems have some way to accomodate that grey area, either by recording a /48 against a residential subscriber or counting them as a class of business customer that pays a residential rate.
Charging a customer extra for more IPv6 addresses just will not fly in a competitive market.
--Michael Dillon
On Thu, Oct 08, 2009 at 10:24:30AM -0400, Curtis Maurand wrote:
Sorry to be a curmudgeon and let me play devil's advocate for a minute. I realize that the address space is enormous; gigantic, even, but if we treat it as cavalierly as you all are proposing, it will get used up. If its treated like an infinite resource that will never, ever be used up as we have done with every other resource on the planet, won't we find ourselves in a heap of trouble?
At this stage we're only 'being cavalier' with 1/8th of the space. We can be more restrictive with the the other 7/8ths if those predicting rapid consumption turn out to be correct. Right now that would be a nice problem to have. Tim
And I will play devil's advocate to the devil's advocate ... wait, does that make me God's advocate? Nice! On Thu, Oct 8, 2009 at 10:24 AM, Curtis Maurand <cmaurand@xyonet.com> wrote:
Sorry to be a curmudgeon and let me play devil's advocate for a minute. I realize that the address space is enormous; gigantic, even, but if we treat it as cavalierly as you all are proposing, it will get used up. If its treated like an infinite resource that will never, ever be used up as we have done with every other resource on the planet, won't we find ourselves in a heap of trouble? Curtis
But the thing is - no-one is proposing we treat it as infinite - just that we treat it the way it was designed to be used. The IETF community "did the math" and decided a /48 per customer was both scalable and sufficient. The community, by and in large, decided that /56s were more appropriate for "small customers" and that is fine, even if some still view it as additional, unneeded complexity. My opinion, based on having done the math as well and operational experience to date, seems to jive that /48s (or even moreso /56s) will work. So let's get to it! /TJ
Sorry to be a curmudgeon and let me play devil's advocate for a minute. I realize that the address space is enormous; gigantic, even, but if we treat it as cavalierly as you all are proposing, it will get used up. If its treated like an infinite resource that will never, ever be used up as we have done with every other resource on the planet, won't we find ourselves in a heap of trouble?
Of course, you are right. That's why, when some people took a close look at the numbers based on a /48 per site, and published their findings, the RIRs made an adjustment to address allocation policy so that it was acceptable to allocate a /56 for a consumer customer, i.e. private residence of some sort. By doing that, they calculated that they could mitigate the small risk that we would run very low on IPv6 addresses around 100 years from now. Having made the change, we are now confident that there are plenty of IPv6 addresses to last more than a century, which basically means that you and your children and your grand children will all be dead when IPv6 gets close to exhaustion. Geoff Huston wrote this: <http://www.potaroo.net/ispcol/2005-07/ipv6size.html> to explain the small risk, and his proposals to adjust the HD ratio and go to a /56 for private residential assignments was basically accepted. If only a few of the biggest cable ISPs use the /56 model, then we are OK. I have great confidence that our descendants will avoid the Idiocracy and be capable of designing and deploying a replacement for IPv6 if that is ever needed. <http://en.wikipedia.org/wiki/Idiocracy> Last time I checked, my taps were still delivering fresh clean "toilet water", not Brawndo energy drink. --Michael Dillon
On 08/10/09 11:46 +0100, Michael Dillon wrote:
There seems to be a variance between "It's OK to just give out a /64" to "You better be thinking about giving out a /48". I can live in those boundaries and am most likely fine with either. I'm leaning toward a /56 for regular subscribers and a /48 only for business or large scale customers, and undecided on dial-up. How does this sound?
The starting point is to give everybody a /48 per site. If a business customer has 3 sites, then give them enough space for a /48 for each site. Could be 3 /48s or could be a /46.
How are other providers approaching dial-up? I would presume we are in the same boat as a lot of other folks - we have aging dial-up equipment that does not support IPv6 (3com Total Control). Our customer base has dropped quite a bit, and we have even kicked around the idea dropping that service and forcing customers to purchase broadband service or go elsewhere. I expect we won't invest any more into dial-up equipment, and when a dial-up customer happens to ask about IPv6 (if ever), we'll strongly encourage them to move to broadband, and as a last resort manually configure a /64 tunnel to them. What are other providers doing, or considering doing? -- Dan White BTC Broadband
How are other providers approaching dial-up? I would presume we are in the same boat as a lot of other folks - we have aging dial-up equipment that does not support IPv6 (3com Total Control). Our customer base has dropped quite a bit, and we have even kicked around the idea dropping that service and forcing customers to purchase broadband service or go elsewhere.
Separate these technical issues from IPv6 allocation plans. If you intend to continue running an ISP in two years from now, either make a simple plan and allocate a /48 to every customer site, whether or not they are currently taking an IPv6 service from you. Or, take the slightly more complex plan and allocate a /56 per site where it is known for sure, 100% that the site is a private residence. If it is not, or there is doubt, then allocate a /48.
I expect we won't invest any more into dial-up equipment, and when a dial-up customer happens to ask about IPv6 (if ever), we'll strongly encourage them to move to broadband, and as a last resort manually configure a /64 tunnel to them.
You might use up a /64 for the two tunnel endpoints, but be sure to allocate the customer at least a /56.
What are other providers doing, or considering doing?
In general, big providers are not going to attempt to cope with any older equipment that does not fully support IPv6. But small providers will be rather innovative and try things like your tunnel suggestion. After all, if Hurricane Electric can run an IPv6 tunnel broker, why can't you? --Michael Dillon
Dan White wrote:
How are other providers approaching dial-up? I would presume we are in the same boat as a lot of other folks - we have aging dial-up equipment that does not support IPv6 (3com Total Control). Our customer base has dropped quite a bit, and we have even kicked around the idea dropping that service and forcing customers to purchase broadband service or go elsewhere.
What are other providers doing, or considering doing?
I'd like to beat this dead horse some more if you gents don't mind. I think there's still some life left in the beast before we haul it off to the glue factory. I'm actually taking an IPv6 class right now and the topic of customer assignments came up today (day 1). The instructor was suggesting dynamically allocating /127s to residential customers. I relayed the gist of this thread to him (/48, /56 and /64). I expect to dive deeper into this in the following days in the class. What are providers doing for residential customers and how does it different from business customers? At what point are you assigning bigger blocks? To go along with Dan's query from above, what are the preferred methods that other SPs are using to deploy IPv6 with non-IPv6-capable edge hardware? We too have a very limited number of dialup customers and will never sink another dollar in the product. Unfortunately I also have brand-new ADSL2+ hardware that doesn't support IPv6 and according to the vendors (Pannaway) never will. We also have CMTSs that don't support IPv6, even though they too are brand-new. Those CMTSs top out at DOCSIS 2.0 and the vendor decided not to allow IPv6 to the CPEs regardless of the underlying CM's IPv6 support or lack thereof (like Cisco allowed for example). Are providers implementing tunneling solutions? Pros/cons of the various solutions? Thanks Justin
On Oct 12, 2009, at 7:34 PM, Justin Shore <justin@justinshore.com> wrote:
I'm actually taking an IPv6 class right now and the topic of customer assignments came up today (day 1). The instructor was suggesting dynamically allocating /127s to residential customers. I relayed the gist of this thread to him (/48, /56 and /64). I expect to dive deeper into this in the following days in the class.
Out of curiosity who is conducting this class and what was their rationale for using /127s? Doug
On 13/10/2009, at 12:54 PM, Doug Barton wrote:
On Oct 12, 2009, at 7:34 PM, Justin Shore <justin@justinshore.com> wrote:
I'm actually taking an IPv6 class right now and the topic of customer assignments came up today (day 1). The instructor was suggesting dynamically allocating /127s to residential customers. I relayed the gist of this thread to him (/48, /56 and /64). I expect to dive deeper into this in the following days in the class.
Out of curiosity who is conducting this class and what was their rationale for using /127s?
Doug
As a point of view on this, a member of staff from APNIC was doing a Masters of IT in the last 3-4 years, and had classfull A/B/C addressing taught to her in the networks unit. She found it quite a struggle to convince the lecturer that reality had moved on and they had no idea about CIDR. I have from time to time, asked people in ACM and IEEE about how one informs the tertiary teaching community about this kind of change. The answers were not inspiring: compared to civil engineering, where compliance issues and re-training by professionals is almost regulated (sorry for the R- word) as a function of professional indemnity insurance and status, its much more common for the syllabus to be under continual review. -George
I'm going to have to pull the "mixed-hat" on this one. If you are comparing this to a true "academia" environment, I'd agree with you. Too much theory, not enough reality in things. However, I've yet to see the part about where the person is being trained from. I happen to train people at CCIE level. I also happen to do consulting, implementation, and design work. In my training environment, there are all sorts of re-thinking of what/how things are being taught even within the confines of comparison to a lab environment. But that's a personal point of view trying to keep reality involved and be worthwhile. I'm not trying to open any sort of debate or can of worms here, but just because one is receiving training does not mean the instructor has no functional knowledge of something. I'm interested in hearing the playout on this one as well. How many addresses do you like on point-to-point circuits? Scott George Michaelson wrote:
On 13/10/2009, at 12:54 PM, Doug Barton wrote:
On Oct 12, 2009, at 7:34 PM, Justin Shore <justin@justinshore.com> wrote:
I'm actually taking an IPv6 class right now and the topic of customer assignments came up today (day 1). The instructor was suggesting dynamically allocating /127s to residential customers. I relayed the gist of this thread to him (/48, /56 and /64). I expect to dive deeper into this in the following days in the class.
Out of curiosity who is conducting this class and what was their rationale for using /127s?
Doug
As a point of view on this, a member of staff from APNIC was doing a Masters of IT in the last 3-4 years, and had classfull A/B/C addressing taught to her in the networks unit. She found it quite a struggle to convince the lecturer that reality had moved on and they had no idea about CIDR.
I have from time to time, asked people in ACM and IEEE about how one informs the tertiary teaching community about this kind of change. The answers were not inspiring: compared to civil engineering, where compliance issues and re-training by professionals is almost regulated (sorry for the R- word) as a function of professional indemnity insurance and status, its much more common for the syllabus to be under continual review.
-George
On 13/10/2009, at 2:02 PM, Scott Morris wrote:
I happen to train people at CCIE level. I also happen to do consulting, implementation, and design work. In my training environment, there are all sorts of re-thinking of what/how things are being taught even within the confines of comparison to a lab environment.
Does the CCNA exam still ask questions about RIP and classful addressing? Just askin' :-) - mark -- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223
No idea, I haven't looked at that stuff in a while. But I would assume so, as it's easier to build a foundation than jumping straight to something difficult? Or did you learn calculus in grade school? Just askin' ;) Scott Mark Newton wrote:
On 13/10/2009, at 2:02 PM, Scott Morris wrote:
I happen to train people at CCIE level. I also happen to do consulting, implementation, and design work. In my training environment, there are all sorts of re-thinking of what/how things are being taught even within the confines of comparison to a lab environment.
Does the CCNA exam still ask questions about RIP and classful addressing?
Just askin' :-)
- mark
-- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223
On 2009-10-13, at 07:39, Scott Morris wrote:
No idea, I haven't looked at that stuff in a while. But I would assume so, as it's easier to build a foundation than jumping straight to something difficult?
I've found RIP to be a reasonable way to teach the concept of a routing protocol, since the protocol is very simple and you can always close with "don't ever use this". But teaching classful routing and addressing is just moronic. It's a foundation that nothing is built on any more, and makes no sense to teach outside of a history class.
Or did you learn calculus in grade school? Just askin' ;)
Yes, since you asked, but your presumption is faulty. Joe
While I may agree that teaching classful routing is stupid, the addressing part lets people start getting the concept of binary. While I'd love to think that people coming out of the school system have a grasp of simple mathematical skills, more and more I'm finding that's not the case. I wouldn't spend a LOT of time with it, and I certainly wouldn't LEAVE at classful addressing, but it's a foundational step. Why is the presumption faulty? If you did calculus, more power to you. However, you still needed a foundation before a pseudo-random collection of letters and numbers together would make any sense. ;) I learned long ago that not everyone can learn in the same fashion that I do. So there's a path to everything with foundations. Some people have a hard time subnetting IPv4 on varying boundaries. More people have a hard time subnetting IPv6 on varying boundaries. While I don't have a problem with either I have to find ways to "fix" those that do while teaching. And typically it's missing foundation skills. But anyway, I don't think that's the important part! My point was more about not assuming that just because someone is teaching that they don't have a realistic set of experiences to go with it as the poster from APNIC pointed out. Just my two cents, Scott Joe Abley wrote:
On 2009-10-13, at 07:39, Scott Morris wrote:
No idea, I haven't looked at that stuff in a while. But I would assume so, as it's easier to build a foundation than jumping straight to something difficult?
I've found RIP to be a reasonable way to teach the concept of a routing protocol, since the protocol is very simple and you can always close with "don't ever use this".
But teaching classful routing and addressing is just moronic. It's a foundation that nothing is built on any more, and makes no sense to teach outside of a history class.
Or did you learn calculus in grade school? Just askin' ;)
Yes, since you asked, but your presumption is faulty.
Joe
On 2009-10-13, at 08:05, Scott Morris wrote:
While I may agree that teaching classful routing is stupid, the addressing part lets people start getting the concept of binary.
That's true of classless addressing, too. When students have problems with non-octet bit boundaries, that just means you start with mask lengths that are multiples of 8.
While I'd love to think that people coming out of the school system have a grasp of simple mathematical skills, more and more I'm finding that's not the case. I wouldn't spend a LOT of time with it, and I certainly wouldn't LEAVE at classful addressing, but it's a foundational step.
Why is the presumption faulty?
You were suggesting that classful addressing is reasonable to teach because it's simpler. It's not simpler, and in a modern-day context it's just wrong. Joe
Ok, fair enough. I was working on the presumption not so much that it was simpler but more than it provided a logical structure. Having some framework to start with provides a base. True that binary is binary is binary... But rather than just an amorphous collection of x-number of bits, there's some initial rhyme and reason. Explaining that, getting buy in, and understanding the limitations therein will make the next progression to VLSM simpler to grasp. At least in my opinion. :) Scott Joe Abley wrote:
On 2009-10-13, at 08:05, Scott Morris wrote:
While I may agree that teaching classful routing is stupid, the addressing part lets people start getting the concept of binary.
That's true of classless addressing, too. When students have problems with non-octet bit boundaries, that just means you start with mask lengths that are multiples of 8.
While I'd love to think that people coming out of the school system have a grasp of simple mathematical skills, more and more I'm finding that's not the case. I wouldn't spend a LOT of time with it, and I certainly wouldn't LEAVE at classful addressing, but it's a foundational step.
Why is the presumption faulty?
You were suggesting that classful addressing is reasonable to teach because it's simpler. It's not simpler, and in a modern-day context it's just wrong.
Joe
On Tue, 13 Oct 2009 08:14:59 -0400 Joe Abley <jabley@hopcount.ca> wrote:
While I may agree that teaching classful routing is stupid, the addressing part lets people start getting the concept of binary.
That's true of classless addressing, too. When students have problems with non-octet bit boundaries, that just means you start [...] You were suggesting that classful addressing is reasonable to teach because it's simpler. It's not simpler, and in a modern-day context it's just wrong.
I occasionally teach college level courses in networking, typically undergrads or grad students at DePaul University. I think I can offer some perspective from both the academic and operator viewpoint. No matter the class or the student, I always have to spend at least a week on IP addressing, even to students who should be coming in with already having had it, sometimes in multiple previous classes. Some know it fairly well, but with holes mostly due to lack of practical experience. I don't think I've seen anyone who would be considered expert enough to withstand the scrutiny of this crowd (though that probably goes for just about anyone really :-). No question about it, but something more than basic classful addressing for students who don't typically have to do it on a regular basis is not easy. Those who aren't afraid of math, can grasp numbering systems and binary arithmetic usually fare better. Some instructors are most certainly doing some harm. From what I can tell, classful addressing is always taught and if classless is taught, its practical reality and importance is not always stressed. In my most recent class this semester I made it abundantly clear to my students that classful addressing, while interesting and useful to know from a historic perspective, is obsolete and deprecated. A student who has another networking related class with another instructor came back saying their other instructor disagrees. :/ John
Heh - Every time I try to say something close to "don't ever use this" or "not really used anymore" WRT RIP I get a student or three that is using it, and in fact it is there only option due to certain vendors' choices of what routing protocols to support on certain classes of gear. /TJ ... really hoping those certain vendors choose OSPFv3 (or ISIS, I really don't care - anything instead of RIPng :P ) for IPv6. On Tue, Oct 13, 2009 at 7:53 AM, Joe Abley <jabley@hopcount.ca> wrote:
On 2009-10-13, at 07:39, Scott Morris wrote:
No idea, I haven't looked at that stuff in a while. But I would assume
so, as it's easier to build a foundation than jumping straight to something difficult?
I've found RIP to be a reasonable way to teach the concept of a routing protocol, since the protocol is very simple and you can always close with "don't ever use this".
But teaching classful routing and addressing is just moronic. It's a foundation that nothing is built on any more, and makes no sense to teach outside of a history class.
Or did you learn calculus in grade school? Just askin' ;)
Yes, since you asked, but your presumption is faulty.
Joe
-- /TJ
The big problem here is that CIDR is tough to teach, even to engineering students. This seems bizarre and counterintuitive, but its true. I know this because I've done it. Its really easy to teach classful addressing, on the other hand. Other problems include the issue that many of the folks teaching have never had to use CIDR in real life, textbook age, and, in some cases, lack of mathematical preparation and inclination on the part of students. Scarier: I was teaching graduate students. - Dan On Oct 13, 2009, at 7:53 AM, Joe Abley wrote:
On 2009-10-13, at 07:39, Scott Morris wrote:
No idea, I haven't looked at that stuff in a while. But I would assume so, as it's easier to build a foundation than jumping straight to something difficult?
I've found RIP to be a reasonable way to teach the concept of a routing protocol, since the protocol is very simple and you can always close with "don't ever use this".
But teaching classful routing and addressing is just moronic. It's a foundation that nothing is built on any more, and makes no sense to teach outside of a history class.
Or did you learn calculus in grade school? Just askin' ;)
Yes, since you asked, but your presumption is faulty.
Joe
I actually think that CIDR is easier to understand than classful addressing. Do the subject completely in binary. It makes complete sense then. - Brian BTW: If the grad students don't get it, fail them! I don't want an engineer who can't grasp basic binary math.
-----Original Message----- From: Daniel Golding [mailto:dgolding@t1r.com] Sent: Friday, October 16, 2009 3:51 PM To: Joe Abley Cc: NANOG Subject: Re: ISP customer assignments
The big problem here is that CIDR is tough to teach, even to engineering students. This seems bizarre and counterintuitive, but its true. I know this because I've done it. Its really easy to teach classful addressing, on the other hand. Other problems include the issue that many of the folks teaching have never had to use CIDR in real life, textbook age, and, in some cases, lack of mathematical preparation and inclination on the part of students.
Scarier: I was teaching graduate students.
- Dan
I've got to agree with Brian, especially in an ISP environment, why would anyone hire or keep someone who couldn't grasp the concept of CIDR? You certainly wouldn't want to have them maintaining a core router with lots of v4 routes, since router-router links are almost always numbered in subnets as small as logic dictates. On 10/16/2009 01:58 PM, Brian Johnson wrote:
I actually think that CIDR is easier to understand than classful addressing. Do the subject completely in binary. It makes complete sense then.
- Brian
BTW: If the grad students don't get it, fail them! I don't want an engineer who can't grasp basic binary math.
-----Original Message----- From: Daniel Golding [mailto:dgolding@t1r.com] Sent: Friday, October 16, 2009 3:51 PM To: Joe Abley Cc: NANOG Subject: Re: ISP customer assignments
The big problem here is that CIDR is tough to teach, even to engineering students. This seems bizarre and counterintuitive, but its true. I know this because I've done it. Its really easy to teach classful addressing, on the other hand. Other problems include the issue that many of the folks teaching have never had to use CIDR in real life, textbook age, and, in some cases, lack of mathematical preparation and inclination on the part of students.
Scarier: I was teaching graduate students.
- Dan
-- Walter Keen Network Technician Rainier Connect (o) 360-832-4024 (c) 253-302-0194
I've taught both. If you try to teach it in Decimal, Hex, or Octal, you're right, it's hard to teach CIDR and easy to teach classful. If you teach it in binary, I have found that not to be an issue. Once you teach it in binary, it's fairly easy to move on to showing how octal and hex are just different representations of binary. Then you show dotted decimal as a really old-fashioned way of representing groups of 8 bits. I've had no trouble teaching it this way, even to people who knew nothing about technology. Owen On Oct 16, 2009, at 1:51 PM, Daniel Golding wrote:
The big problem here is that CIDR is tough to teach, even to engineering students. This seems bizarre and counterintuitive, but its true. I know this because I've done it. Its really easy to teach classful addressing, on the other hand. Other problems include the issue that many of the folks teaching have never had to use CIDR in real life, textbook age, and, in some cases, lack of mathematical preparation and inclination on the part of students.
Scarier: I was teaching graduate students.
- Dan
On Oct 13, 2009, at 7:53 AM, Joe Abley wrote:
On 2009-10-13, at 07:39, Scott Morris wrote:
No idea, I haven't looked at that stuff in a while. But I would assume so, as it's easier to build a foundation than jumping straight to something difficult?
I've found RIP to be a reasonable way to teach the concept of a routing protocol, since the protocol is very simple and you can always close with "don't ever use this".
But teaching classful routing and addressing is just moronic. It's a foundation that nothing is built on any more, and makes no sense to teach outside of a history class.
Or did you learn calculus in grade school? Just askin' ;)
Yes, since you asked, but your presumption is faulty.
Joe
On Oct 16, 2009, at 5:19 PM, Owen DeLong wrote:
I've taught both. If you try to teach it in Decimal, Hex, or Octal, you're right, it's hard to teach CIDR and easy to teach classful.
It really does not matter the representation as long as you divide your Address Pie with a Binary Knife. Once you understand that -- 1/2, 1/2 of 1/2, 1/2 of 1/2 of 1/2, ... -- then you should understand CIDR. Then, as Owen suggests, deal with the representation. Works for IPv4, IPv6, and, probably, IPv8. ;) Warning, strong opinion follows: One should never have to mention Classful addressing except to note that it is archaic, anachronistic, and used only by those who remain ignorant by preference. James R. Cutler james.cutler@consultant.com
On Tue, 13 Oct 2009 07:39:46 EDT, Scott Morris said:
No idea, I haven't looked at that stuff in a while. But I would assume so, as it's easier to build a foundation than jumping straight to something difficult?
Unfortunately, classful addressing is a foundation for networking the same way Roman numerals were a foundation for arithmetic. Both are "the way we used to do it", neither is relevant anymore, and once learned, both are bad habits that actively inhibit learning the more useful methods... And yes, as a matter of fact, I *did* start learning calculus in grade school. Have to admit that partial derivatives stumped me until middle school, though.
On Mon, 12 Oct 2009 23:32:23 -0400 Scott Morris <swm@emanon.com> wrote:
I'm going to have to pull the "mixed-hat" on this one. If you are comparing this to a true "academia" environment, I'd agree with you. Too much theory, not enough reality in things. However, I've yet to see the part about where the person is being trained from.
I happen to train people at CCIE level. I also happen to do consulting, implementation, and design work. In my training environment, there are all sorts of re-thinking of what/how things are being taught even within the confines of comparison to a lab environment. But that's a personal point of view trying to keep reality involved and be worthwhile.
I'm not trying to open any sort of debate or can of worms here, but just because one is receiving training does not mean the instructor has no functional knowledge of something. I'm interested in hearing the playout on this one as well.
How many addresses do you like on point-to-point circuits?
How ever many the protocol designers thought there should be.
Scott
George Michaelson wrote:
On 13/10/2009, at 12:54 PM, Doug Barton wrote:
On Oct 12, 2009, at 7:34 PM, Justin Shore <justin@justinshore.com> wrote:
I'm actually taking an IPv6 class right now and the topic of customer assignments came up today (day 1). The instructor was suggesting dynamically allocating /127s to residential customers. I relayed the gist of this thread to him (/48, /56 and /64). I expect to dive deeper into this in the following days in the class.
Out of curiosity who is conducting this class and what was their rationale for using /127s?
Doug
As a point of view on this, a member of staff from APNIC was doing a Masters of IT in the last 3-4 years, and had classfull A/B/C addressing taught to her in the networks unit. She found it quite a struggle to convince the lecturer that reality had moved on and they had no idea about CIDR.
I have from time to time, asked people in ACM and IEEE about how one informs the tertiary teaching community about this kind of change. The answers were not inspiring: compared to civil engineering, where compliance issues and re-training by professionals is almost regulated (sorry for the R- word) as a function of professional indemnity insurance and status, its much more common for the syllabus to be under continual review.
-George
On Mon, Oct 12, 2009 at 8:32 PM, Scott Morris <swm@emanon.com> wrote:
How many addresses do you like on point-to-point circuits?
Scott
I allocate a /64, but currently I configure only a /127 subnet on the actual interface. That prevents the neighbor table explosion/NS/ND traffic flooding challenges that can occur otherwise if you configure the link as a /64, and some not-nice person decides to start ping sweeping or nmapping the subnet; your router has to send out NS messages for every address in the /64 being probed, update the neighbor table with the incomplete entry, then flush it out when no ND message is seen. On a point-to-point link between routers you're never going to run stateless autoconfiguration, so there's not much downside to configuring it as a /127. Still...just in case, I do allocate the whole /64 for the link, so that if in the future it turns out that for some reason it really, *really* does have to be a /64 configured on it, I can make the change just by adjusting masks on each end, rather than having to actually renumber the entire network. *shrug* As always, your mileage will vary, but this has worked out well for me so far. Matt
On 2009-10-13, at 14:46, Matthew Petach wrote:
I allocate a /64, but currently I configure only a /127 subnet on the actual interface.
For BRAS/PPPoE deployments you're dealing with a point-to-point link, so in principle you can number the endpoints using whatever you want. They're just host addresses and interface routes when it comes down to it. There's no need to number both ends within a single conventional subnet. In the test deployment I did earlier in the year I defined a pool of link addresses per BRAS (one /64 prefix per BRAS) and handed out one to each subscriber using ND/RA after IPv6CP had completed. To the subscriber that looked like a /128 host route, with some other arbitrary address on the far side. (We could have done it with RADIUS too, but having a static link address didn't seem particularly important.) A sub-side static /48 was then assigned via RADIUS and a route installed on the BRAS side, with DHCPv6 PD available as an option for clients who want auto-configuration rather than static config. It seemed to work. BRAS was a Juniper E-series (test box was an ERX310). Joe
On Oct 13, 2009, at 9:56 PM, Joe Abley wrote:
On 2009-10-13, at 14:46, Matthew Petach wrote:
I allocate a /64, but currently I configure only a /127 subnet on the actual interface.
For BRAS/PPPoE deployments you're dealing with a point-to-point link, so in principle you can number the endpoints using whatever you want. They're just host addresses and interface routes when it comes down to it. There's no need to number both ends within a single conventional subnet.
In the test deployment I did earlier in the year I defined a pool of link addresses per BRAS (one /64 prefix per BRAS) and handed out one to each subscriber using ND/RA after IPv6CP had completed. To the subscriber that looked like a /128 host route, with some other arbitrary address on the far side. (We could have done it with RADIUS too, but having a static link address didn't seem particularly important.)
A sub-side static /48 was then assigned via RADIUS and a route installed on the BRAS side, with DHCPv6 PD available as an option for clients who want auto-configuration rather than static config.
It seemed to work. BRAS was a Juniper E-series (test box was an ERX310).
We run roughly the same, although we skip the whole globalscope address on the PPP, running localscope only works for the CPE we tested so far. MarcoH
That was the point. :) Scott Matthew Petach wrote:
On Mon, Oct 12, 2009 at 8:32 PM, Scott Morris <swm@emanon.com <mailto:swm@emanon.com>> wrote:
How many addresses do you like on point-to-point circuits?
Scott
I allocate a /64, but currently I configure only a /127 subnet on the actual interface. That prevents the neighbor table explosion/NS/ND traffic flooding challenges that can occur otherwise if you configure the link as a /64, and some not-nice person decides to start ping sweeping or nmapping the subnet; your router has to send out NS messages for every address in the /64 being probed, update the neighbor table with the incomplete entry, then flush it out when no ND message is seen. On a point-to-point link between routers you're never going to run stateless autoconfiguration, so there's not much downside to configuring it as a /127.
Still...just in case, I do allocate the whole /64 for the link, so that if in the future it turns out that for some reason it really, *really* does have to be a /64 configured on it, I can make the change just by adjusting masks on each end, rather than having to actually renumber the entire network.
*shrug* As always, your mileage will vary, but this has worked out well for me so far.
Matt
How many addresses do you like on point-to-point circuits?
That will become one of those great interview questions, because anyone who says something like "a /127" or "a /64" will be someone that you probably don't want to hire. The right answer is to explain that there are some issues surrounding the choice of addressing on point-to-point circuits and there has even been an RFC published discussing these issues, RFC 3627 <http://www.ietf.org/rfc/rfc3627.txt> The right decision for one network, or for one point in the topology, might not be the right decision for some other place. Some people may learn this by rote as a rule to always use a /126 or a /112 for point-to-point links, but even then it is best to understand why. --Michael Dillon
Once upon a time, Michael Dillon <wavetossed@googlemail.com> said:
How many addresses do you like on point-to-point circuits?
That will become one of those great interview questions, because anyone who says something like "a /127" or "a /64" will be someone that you probably don't want to hire.
The right answer is to explain that there are some issues surrounding the choice of addressing on point-to-point circuits and there has even been an RFC published discussing these issues, RFC 3627 <http://www.ietf.org/rfc/rfc3627.txt>
Still learning here, so please go easy... I read the above, and I see section 4 item 3 says: The author feels that if /64 cannot be used, /112, reserving the last 16 bits for node identifiers, has probably the least amount of drawbacks (also see section 3). I guess I'm missing something; what in section 3 is this referring to? I can understand /64 or /126 (or maybe /124 if you were going to delegate reverse DNS?), but why /112 and "16 bits for node identifiers" on a point-to-point link? -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
On Oct 13, 2009, at 4:26 PM, Chris Adams wrote:
Once upon a time, Michael Dillon <wavetossed@googlemail.com> said:
How many addresses do you like on point-to-point circuits?
That will become one of those great interview questions, because anyone who says something like "a /127" or "a /64" will be someone that you probably don't want to hire.
The right answer is to explain that there are some issues surrounding the choice of addressing on point-to-point circuits and there has even been an RFC published discussing these issues, RFC 3627 <http://www.ietf.org/rfc/rfc3627.txt>
Still learning here, so please go easy...
I read the above, and I see section 4 item 3 says:
The author feels that if /64 cannot be used, /112, reserving the last 16 bits for node identifiers, has probably the least amount of drawbacks (also see section 3).
I guess I'm missing something; what in section 3 is this referring to? I can understand /64 or /126 (or maybe /124 if you were going to delegate reverse DNS?), but why /112 and "16 bits for node identifiers" on a point-to-point link?
I'm actually completely unclear why people would use anything but a / 126 in 90% or more of cases. For all intensive purposes a /126 translates to a /30 in IPv4. Do people assign /24's to their point to point links today with IPv4? What's the point of a /64 on a point to point link? I'm not clear why people would intentionally be so frivolous with their IP space simply for the sake of "because I can."
On Tue, Oct 13, 2009 at 6:34 PM, Cord MacLeod <cordmacleod@gmail.com> wrote:
IPv4? What's the point of a /64 on a point to point link? I'm not clear
IP Addressing uniformity and simplicity. Use of /127s for Point-to-Point links introduces addressing complexity that may be avoided in V6: the scarcity of IPs necessitated it in V4 . At least /112 lies on an even 16-bit boundary, and that makes it the longest prefix that is a very good choice, if you do need a non-standard mask. Unless you have only a /32 of V6 space and 1 billion P2Pt links you need (or similar scenario), there is no utility in practicing rampant prefix length expansion, for the purpose of conservation (there may be other reasons such as preventing autoconfig).
For all intensive purposes a /126 translates to a /30 in IPv4. Do people assign /24's to their point to point links today with
Not really; there's a massive difference of scale. Say there's a big vat that contains all gold in the universe, you get to bring home one bucket of gold flakes to allocate to your customers. In the V4 universe, well you got a /19.. You got a 60 kilogram bucket, and a /30 represents a 1 troy ounce scoop taken out of that bucket.. In the V6 universe, even if you got a measly /48: one /64 from that is a 1 troy ounce gold flake out of your 2000 kilogram bucket. Should you really be worried about cutting up that flake? In reality... if you're an ISP the worst you have is a /32, you can think of a /48 that way, you do have 65536 of those /48s, also known as a 133,588,416kg bucket, since your /32 has a maximum of 4 billion /64s. Normally when you have a P2P link, it will mean you connect an end site also: that end site gets a /48 (Per the justification that allows you as an ISP to get a /32, such a large allocation). After assigning 65536 /64s, or 256 /64s (if you give out /56s to end sites) which you already do for each _end site_ as standard address allocation practice in V6, what's another single /64, seriously? -- -J
Chris Adams wrote:
I guess I'm missing something; what in section 3 is this referring to? I can understand /64 or /126 (or maybe /124 if you were going to delegate reverse DNS?), but why /112 and "16 bits for node identifiers" on a point-to-point link?
The only thing special about /112 is that it is on a ":" boundary so it makes for some nice numbering plans: Let's say you set aside 2001:xxxx:0:1::/64 for /112's link 1: 2001:xxxx:0:1::1:1 2001:xxxx:0:1::1:2 link 2: 2001:xxxx:0:1::2:1 2001:xxxx:0:1::2:2 This :1, :2 arrangement seems to be common but for internal links you could make the last hextet be a unique id for the specific router. That could use more than a few bits in a large network. - Kevin
In a message written on Tue, Oct 13, 2009 at 06:26:20PM -0500, Chris Adams wrote:
The author feels that if /64 cannot be used, /112, reserving the last 16 bits for node identifiers, has probably the least amount of drawbacks (also see section 3).
I guess I'm missing something; what in section 3 is this referring to? I can understand /64 or /126 (or maybe /124 if you were going to delegate reverse DNS?), but why /112 and "16 bits for node identifiers" on a point-to-point link?
We use /112's, and do so for two (and a half) reasons: 1) If you think of all possible "network to network" interconnects they include the simple case like a single router on both ends, but they also include cases like two routers on one or both ends, and optionally with VRRP/HSRP. Maximally it appears 6 IP's may be required (two routers both ends, plus vrrp on each, statics at the VRRP). So it makes sense to have a 8 or 16 block of IP's per link so you never have to renumber the link if you switch these configurations. 2) Colon's separate 16 bit chunks in IPv6. /112's allow XXXX::1, XXXX::2 to be your IP's. The half a reason, if you have a /64 dedicate to point to point links, and use /112's, you have 2^(112-64) possible links. That's 281 trillion point to point links. Given 1, and 2, and the numbers /127's, /126's, /125's don't make any sense when you can standardize on one size fits all, and never run out. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
Once upon a time, Leo Bicknell <bicknell@ufp.org> said:
2) Colon's separate 16 bit chunks in IPv6. /112's allow XXXX::1, XXXX::2 to be your IP's.
Yeah, this is what I forgot about. Makes sense now. Another (quite possibly dumb :-) ) few questions come to mind about IPv6 assignment: I would expect you just assign static addresses to servers. Are there pros/cons to using /64 or something else there? If I'm statically assigning IP (and DNS, etc. servers) info, why would I not just configure the gateway there as well (especially if you just make all local router interfaces ::1)? What about web-hosting type servers? Right now, I've got a group of servers in a common IPv4 subnet (maybe a /26), with a /24 or two routed to each server for hosted sites. What is the IPv6 equivalent? I can see a /64 for the common subnet, but what to route for aliased IPs for web hosts? It is kind of academic right now, since our hosting control panel software doesn't handle IPv6, but I certainly won't be putting 2^64 sites on a single server. Use a /112 here again as well? Use a /64 per server because I can? What about anycast-type addresses (e.g. DNS servers)? I route a few server IPv4 /32s around in my network; do you assign a /128, a /64 (with only one address in use), a /112, or something else? -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
In a message written on Tue, Oct 13, 2009 at 08:14:40PM -0500, Chris Adams wrote:
I would expect you just assign static addresses to servers. Are there pros/cons to using /64 or something else there? If I'm statically assigning IP (and DNS, etc. servers) info, why would I not just configure the gateway there as well (especially if you just make all local router interfaces ::1)?
All of our servers are in binary coded hex. :) That is, if your IPv4 address is 10.12.3.187, your IPv6 address is A:B:C:D::187. The router is ::1, just as in IPv4, and servers have static routes. We still use /64's everywhere. You may want to use temporary (privacy) addresses outbound. You many want to allow a server to use EUI-64 to get an address while doing an install, or similar.
What about anycast-type addresses (e.g. DNS servers)? I route a few server IPv4 /32s around in my network; do you assign a /128, a /64 (with only one address in use), a /112, or something else?
/128's for loopbacks, anycast addreses, and similar here. Typically out of a loopback /64. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
" What about anycast-type addresses (e.g. DNS servers)? I route a few server IPv4 /32s around in my network; do you assign a /128, a /64 (with only one address in use), a /112, or something else?" Yes, on any sort of multi-access segment you really should use /64s. A little less stringent on an all router segment perhaps, but even then I shoot for /64s on anything that is not a PtP link ... /TJ -----Original Message----- From: Chris Adams [mailto:cmadams@hiwaay.net] Sent: Tuesday, October 13, 2009 9:15 PM To: nanog@nanog.org Subject: Re: ISP customer assignments Once upon a time, Leo Bicknell <bicknell@ufp.org> said:
2) Colon's separate 16 bit chunks in IPv6. /112's allow XXXX::1, XXXX::2 to be your IP's.
Yeah, this is what I forgot about. Makes sense now. Another (quite possibly dumb :-) ) few questions come to mind about IPv6 assignment: I would expect you just assign static addresses to servers. Are there pros/cons to using /64 or something else there? If I'm statically assigning IP (and DNS, etc. servers) info, why would I not just configure the gateway there as well (especially if you just make all local router interfaces ::1)? What about web-hosting type servers? Right now, I've got a group of servers in a common IPv4 subnet (maybe a /26), with a /24 or two routed to each server for hosted sites. What is the IPv6 equivalent? I can see a /64 for the common subnet, but what to route for aliased IPs for web hosts? It is kind of academic right now, since our hosting control panel software doesn't handle IPv6, but I certainly won't be putting 2^64 sites on a single server. Use a /112 here again as well? Use a /64 per server because I can? What about anycast-type addresses (e.g. DNS servers)? I route a few server IPv4 /32s around in my network; do you assign a /128, a /64 (with only one address in use), a /112, or something else?
On 14/10/2009, at 2:14 PM, Chris Adams wrote:
What about web-hosting type servers? Right now, I've got a group of servers in a common IPv4 subnet (maybe a /26), with a /24 or two routed to each server for hosted sites. What is the IPv6 equivalent? I can see a /64 for the common subnet, but what to route for aliased IPs for web hosts? It is kind of academic right now, since our hosting control panel software doesn't handle IPv6, but I certainly won't be putting 2^64 sites on a single server. Use a /112 here again as well? Use a /64 per server because I can?
Why route them to the servers? I would just put up a /64 for the web servers and bind addresses to your ethernet interface out of that /64 as they are used by each site. I guess you might want to route them to the servers to save ND entries or something on your router? -- Nathan Ward
Once upon a time, Nathan Ward <nanog@daork.net> said:
On 14/10/2009, at 2:14 PM, Chris Adams wrote:
What about web-hosting type servers? Right now, I've got a group of servers in a common IPv4 subnet (maybe a /26), with a /24 or two routed to each server for hosted sites. What is the IPv6 equivalent? I can see a /64 for the common subnet, but what to route for aliased IPs for web hosts? It is kind of academic right now, since our hosting control panel software doesn't handle IPv6, but I certainly won't be putting 2^64 sites on a single server. Use a /112 here again as well? Use a /64 per server because I can?
Why route them to the servers? I would just put up a /64 for the web servers and bind addresses to your ethernet interface out of that /64 as they are used by each site. I guess you might want to route them to the servers to save ND entries or something on your router?
In the past, we saw issues with thousands of ARP entries (it has been a while and I don't remember what issues now though). Moving a block from one server to another didn't require clearing an ARP cache (and triggering a couple of thousand new ARP requests). Also, it is an extra layer of misconfiguration-protection: if the IPs are routed, accidentally assigning the wrong IP on the wrong server didn't actually break any existing sites (and yes, that is a lesson from experience). Of course, with IPv4, you never assigned a large enough block to begin with that would anticipate all growth, so routing additional blocks was a lot easier than changing blocks, cleaner than secondary IPs multiplying like crazy, etc., etc. None of that would be an issue with a single /64. -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
On 14/10/2009, at 3:49 PM, Chris Adams wrote:
Once upon a time, Nathan Ward <nanog@daork.net> said:
On 14/10/2009, at 2:14 PM, Chris Adams wrote:
What about web-hosting type servers? Right now, I've got a group of servers in a common IPv4 subnet (maybe a /26), with a /24 or two routed to each server for hosted sites. What is the IPv6 equivalent? I can see a /64 for the common subnet, but what to route for aliased IPs for web hosts? It is kind of academic right now, since our hosting control panel software doesn't handle IPv6, but I certainly won't be putting 2^64 sites on a single server. Use a /112 here again as well? Use a /64 per server because I can?
Why route them to the servers? I would just put up a /64 for the web servers and bind addresses to your ethernet interface out of that /64 as they are used by each site. I guess you might want to route them to the servers to save ND entries or something on your router?
In the past, we saw issues with thousands of ARP entries (it has been a while and I don't remember what issues now though). Moving a block from one server to another didn't require clearing an ARP cache (and triggering a couple of thousand new ARP requests).
Yeah I figured as much.
Also, it is an extra layer of misconfiguration-protection: if the IPs are routed, accidentally assigning the wrong IP on the wrong server didn't actually break any existing sites (and yes, that is a lesson from experience).
I guess. The advantage of doing it with a single /64 for all of them is that you can move individual sites to other servers without much drama. That might not be useful for everyone of course. -- Nathan Ward
Of course, with IPv4, you never assigned a large enough block to begin with that would anticipate all growth, so routing additional blocks was a lot easier than changing blocks, cleaner than secondary IPs multiplying like crazy, etc., etc. None of that would be an issue with a single /64.
You've hit on the key difference of IPv6. With IPv6 you should design your network so that it can grow for a long time without increasing the address block sizes anywhere. A /64 will work for even the biggest subnets. A /48 will do for for very, very big sites. And only the largest ISPs will outgrow a /32 allocation. If you assign a /48 to a data center site, then when you subnet it, try to maintain that growth ability if you can. Don't skimp on address block sizes unless you are backed into a corner for technical or business reasons. --Michael Dillon
Once upon a time, Michael Dillon <wavetossed@googlemail.com> said:
And only the largest ISPs will outgrow a /32 allocation.
This brings up something else I'm trying to figure out. We're not a huge ISP; I've got our /32 but I don't see us using more. We have two main POPs, each with Internet links, plus a link between the two. Our IPv4 allocations are larger than the minimum, so I split our IPv4 space between the two POPs and avertise a smaller block out of the smaller of the two POPs. This has worked okay and handles the POP-to-POP link going down; when that happens, our POP-to-POP traffic (not a large precentage of our traffic) goes across our Internet connections, but Internet traffic for each POP goes to directly to the POP. With IPv6, we've got our single /32. From what I understand, if I try to advertise a /33 from the smaller POP, many (most?) will drop it (if my upstreams even take it). If I advertise the /32 from both routers, when that link goes down, my IPv6 traffic will be pretty much hosed. Is there any good solution to this? I don't expect us to fill the /32 to justify expanding it (although I do see ARIN appears to have left space for up to a /29; I guess that's their sparse allocation policy?). I guess this is traffic engineering, although I'm not deaggregating to try to control how much goes where, just to ensure connectivity in the face of failures. This link has been pretty reliable lately (since the telco re-engineered it), but it was flakey as hell a while back (when it went through 7 companies to go between cities 90 miles apart). -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
On 16/10/2009, at 1:17 PM, Chris Adams wrote:
Is there any good solution to this? I don't expect us to fill the /32 to justify expanding it (although I do see ARIN appears to have left space for up to a /29; I guess that's their sparse allocation policy?).
Your justification is that you have two sites without a guaranteed link between them. This is a bit annoying though, yeah. But, I'm not sure I can think of a good solution that doesn't involve us changing the routing system so that we can handle a huge amount of intentional de-aggregates or something. -- Nathan Ward
Nathan Ward wrote:
On 16/10/2009, at 1:17 PM, Chris Adams wrote:
Is there any good solution to this? I don't expect us to fill the /32 to justify expanding it (although I do see ARIN appears to have left space for up to a /29; I guess that's their sparse allocation policy?).
Your justification is that you have two sites without a guaranteed link between them.
This is a bit annoying though, yeah. But, I'm not sure I can think of a good solution that doesn't involve us changing the routing system so that we can handle a huge amount of intentional de-aggregates or something.
-- Nathan Ward
Actually, as of right now that's not justification. The Multiple Discrete Networks policy that's up for a vote in Dearborn will allow for this, but right now there's no IPv6 equivalent of that policy. -Dave
This is a bit annoying though, yeah. But, I'm not sure I can think of a good solution that doesn't involve us changing the routing system so that we can handle a huge amount of intentional de-aggregates or something.
Within the RIPE region we're currently discussing a document on IPv6 route aggregation that acknowledges there are cases where it may be necessary to break up a /32 into a limited number of smaller blocks. Following discussion at the meeting last week I need to revise it, but the previous draft is here: http://www.ripe.net/ripe/maillists/archives/routing-wg/2009/msg00120.html Cheers, Rob
On Thu, Oct 15, 2009 at 8:17 PM, Chris Adams <cmadams@hiwaay.net> wrote:
With IPv6, we've got our single /32. From what I understand, if I try to advertise a /33 from the smaller POP, many (most?) will drop it (if my upstreams even take it). If I advertise the /32 from both routers, when that link goes down, my IPv6 traffic will be pretty much hosed. Is there any good solution to this?
Chris, Here's what I do with my IPv4 /24: I advertise it at higher priority at the larger POP and a slightly lower priority at the smaller POP. Then I got a small block of addresses from each upstream at each POP (from their still-aggregated blocks) to anchor a set of VPNs between the two. Something has to go disastrously wrong for me to suffer any worse effects than the occasional inefficient routing. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
* Chris Adams
This brings up something else I'm trying to figure out. We're not a huge ISP; I've got our /32 but I don't see us using more. We have two main POPs, each with Internet links, plus a link between the two. Our IPv4 allocations are larger than the minimum, so I split our IPv4 space between the two POPs and avertise a smaller block out of the smaller of the two POPs.
This has worked okay and handles the POP-to-POP link going down; when that happens, our POP-to-POP traffic (not a large precentage of our traffic) goes across our Internet connections, but Internet traffic for each POP goes to directly to the POP.
With IPv6, we've got our single /32. From what I understand, if I try to advertise a /33 from the smaller POP, many (most?) will drop it (if my upstreams even take it). If I advertise the /32 from both routers, when that link goes down, my IPv6 traffic will be pretty much hosed.
What you can do is to set up a tunnel between the sites (can be encrypted if necessary) through your upstream(s), and include it in your IGP - making sure that it has a higher cost/metric than the dedicated circuit. If then the dedicated circuit goes down, the traffic between the PoPs is redirected through the tunnel, and no connectivity is lost. You might need to upgrade the capacity of the dedicated circuit though, since there's no avoiding that some inbound packets will be delivered to the wrong PoP. Also you should make sure that the ports to your upstreams have enough available burst capacity (and preferably a roomy percentile-based charging scheme so that a bit of downtime on the dedicated circuit won't cost you anything). If you're single-homing to the the same upstream AS at both sites, another solution is to announce the aggregate /32 from both PoPs and at the same time a more specific route from each of them tagged with the no-export community (assuming your upstream will accept the deaggregated route in both locations). Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27
In a message written on Tue, Oct 13, 2009 at 08:14:40PM -0500, Chris Adams wrote: <..>
What about web-hosting type servers? Right now, I've got a group of servers in a common IPv4 subnet (maybe a /26), with a /24 or two routed to each server for hosted sites. What is the IPv6 equivalent? I can see a /64 for the common subnet, but what to route for aliased IPs for web hosts? It is kind of academic right now, since our hosting control panel software doesn't handle IPv6, but I certainly won't be putting 2^64 sites on a single server. Use a /112 here again as well? Use a /64 per server because I can?
I'd be interested in any suggestions on this part as well. We're a Hosting provider and basicly we have (for now) 3 different product-groups we want to launch IPv6 on : 1 - Shared Hosting These servers (Linux), are all in 1 vlan. Each server has 1 IPv4 address from the subnet that's configured on the vlan. Then we have an IPv4 /24 routed to each of the servers (each server has 1 /24 to host sites on). Here I'd assign a single /64 and use static addressing. 2 - Premium Managed & Unmanaged Hosting (Co-location). Each customer has one (or more) dedicated subnets and vlans. Here I'd assign a /64 per vlan. I'd do static addressing for Managed, but probably provide RA (EUI-64) for Unmanaged. 3 - Managed and Umanaged Hosting (Co-location). These servers are in 'shared' subnets, ranging from /23 to /26, and each customer get's assigned at least 1 IP from this subnet and more if they can justify. For customers needing 'large' subnets, we'd route a different subnet to their server of choice. Here, I'm not sure what to do... You should at least assign a /64 per customer, but how would one do that when they are in shared subnets/vlans... ? If for every server I'd need to assign a /64 secondary to our vlan interfaces, I'd trip the maximums (Nortel Passport 8600 used for these customers has quite some limitations on IPv6). It would be nice though, cause once IPv4 is no longer used (...) we could move customers to another/dedicated vlan. We've also fiddled with the idea of assigning one /48 to each of these vlans, and let each 'server' use a /64 out of it. This still seems a bit weird though... Also, since we do IP based billing here, we'd never know if one has 'hijacked' some IP space. Yes, we'd know for un-assigned addresses (not assigned but has traffic -> alert), but I don't expect a customer to use all addresses out of 'their' /64, so the not used addresses could be easily be abused. For IPv4, all addresses are usually really used and the customer who's IP's are hijacked, would almost definitely hang on the phone in no-time. Some advice would be very appreciated. Best regards, Wouter de Jong WideXS
Chris Adams wrote:
I guess I'm missing something; what in section 3 is this referring to? I can understand /64 or /126 (or maybe /124 if you were going to delegate reverse DNS?), but why /112 and "16 bits for node identifiers" on a point-to-point link?
It falls on a 16 bit boundry and is therefore easy to read. some numbering concessions within a vast space exist for the convenience of the poor humans not the machines. I can pick out the host side of the address in a /64 no problem but for some reason I have a trouble finding subnet boundaries on a series of /93s.
George Michaelson wrote:
As a point of view on this, a member of staff from APNIC was doing a Masters of IT in the last 3-4 years, and had classfull A/B/C addressing taught to her in the networks unit. She found it quite a struggle to convince the lecturer that reality had moved on and they had no idea about CIDR.
I'm ok with teaching it to beginners to explain where we came from but that should be it. It should be made excruciatingly clear in the training that it's no longer done that way because we found a MUCH better way of doing things. That said I still occasionally refer to networks in classful terms and I can think of several network engineers who have years of enterprise experience that still don't understand CIDR. Justin
I'm ok with teaching it to beginners to explain where we came from but that should be it.
But why does that have to be done first? Why can't they teach current best practice in addressing, and then point out that historically it was done different but that caused problems which led to today's system?
That said I still occasionally refer to networks in classful terms and I can think of several network engineers who have years of enterprise experience that still don't understand CIDR.
I'm very careful about classful terminology because I work with a team of engineers who still occasionally must deal with a customer network (using very old gear) which requires class C addressing. For those who don't know what a Class C address is, it is an IP address in the range 192.0.0.0 to 223.255.255.255, i.e. it begins with binary 110, and the network prefix is fixed at /24. This means that 10.2.3/24 is not a class C address, and 192.2/16 is not a legal address block. --Michael Dillon
If you've got an addressing system with enough bits that you don't have to start stealing them, it makes sense to pick some boundary length between our-problem : their-problem 128 bits is long enough, and changing protocols is nasty enough, that it should let you Never Have To Do It Again. Originally with IPv6, the boundary was a nice round 64 bits, with the ISP on the network side and MAC48-based autoaddressing on the user side, with the user side looking suspiciously similar to Novell Netware and giving ~64K subnets, and this was back before DHCP had taken over the world and it was expected that all kinds of weird little toasters would be using IPv6. But some relatively sensible people proposed using the (ugly) EUI-64 64-bit MAC, because they Never Wanted To Have To Do This Again Either. And unfortunately, because it's a good enough idea to be worth accepting, it pushes the network boundary somewhat to the left, because it's pretty obvious that an average household may have multiple devices that want to autoconfigure themselves, so you probably will end up needing multiple subnets. And unfortunately, there's no obviously correct boundary, and no particular reason for all ISPs to use the same boundary, so there are endless arguments about it on NANOG and elsewhere. In general, /48's big enough for most large complex businesses (except ISPs), and /60's more than big enough for a household and for many small businesses, but we've got enough bits that it's worth using octet-aligned addresses, so /56 is the magic number for them, except at ISPs that simply don't want to bother giving out anything except /48s. There may be special cases for assigning /64s to end users, such as IPv6-equipped cell phones, but that's a matter for specialized carriers to provide, or for internal network managers at enterprises. And if you're big enough to get Provider Independent Address Space and an AS#, you're big enough to have a /48 of your own. Now, IPv6 was supposed to allow the development of other indistinguishable-from-magically advanced technology, such as getting rid of the growth of routing tables by convincing everybody to be happy with hierarchically assigned provider-aligned address space, and unfortunately that hasn't matched the needs of businesses, which need multihoming for reliability (so they'll be non-provider-aligned for at least n-1 of their ISPs), plus want the ability to take their address space with them when they change ISPs (because there are too many devices and applications that insist on having hard-coded IP addresses instead of using DNS, and because DNS tends to get cached more often than you'd sometimes like. So that problem shows no sign of going away (in spite of shim6..)
On 20/10/2009, at 3:02 PM, Bill Stewart wrote:
plus want the ability to take their address space with them when they change ISPs (because there are too many devices and applications that insist on having hard-coded IP addresses instead of using DNS, and because DNS tends to get cached more often than you'd sometimes like.
That's why we have Unique Local Addresses. -- Nathan Ward
On Tue, Oct 20, 2009 at 03:07:39PM +1300, Nathan Ward wrote:
On 20/10/2009, at 3:02 PM, Bill Stewart wrote:
plus want the ability to take their address space with them when they change ISPs (because there are too many devices and applications that insist on having hard-coded IP addresses instead of using DNS, and because DNS tends to get cached more often than you'd sometimes like.
That's why we have Unique Local Addresses.
but Nathan, they are only statistically unique. --bill
On 20/10/2009, at 3:10 PM, bmanning@vacation.karoshi.com wrote:
On Tue, Oct 20, 2009 at 03:07:39PM +1300, Nathan Ward wrote:
On 20/10/2009, at 3:02 PM, Bill Stewart wrote:
plus want the ability to take their address space with them when they change ISPs (because there are too many devices and applications that insist on having hard-coded IP addresses instead of using DNS, and because DNS tends to get cached more often than you'd sometimes like.
That's why we have Unique Local Addresses.
but Nathan, they are only statistically unique.
Sure, but I don't think that changes my point. Also if you want to increase your chances of uniqueness (which are already pretty good if you're not using subnet 0 or 1 or whatever) you can jump on to somewhere on the sixxs site and announce that you're using a specific ULA prefix. -- Nathan Ward
On Mon, Oct 19, 2009 at 7:07 PM, Nathan Ward <nanog@daork.net> wrote:
On 20/10/2009, at 3:02 PM, Bill Stewart wrote:
plus want the ability to take their address space with them when they change ISPs (because there are too many devices and applications that insist on having hard-coded IP addresses instead of using DNS, and because DNS tends to get cached more often than you'd sometimes like.
That's why we have Unique Local Addresses.
This is the opposite problem - ULAs are for internal devices, and what businesses often want is globally routable non-provider-owned public addresses. If you've got a VPN tunnel device, too often the remote end will want to contact you at some numerical IPv4 address and isn't smart enough to query DNS to get it. And even though most enterprises these days only use registered addresses outside the firewall and not inside the firewall, it's still a pain to have to renumber everything and wait for everybody's DNS caches to expire, so if you're using Provider-independent IP addresses, it's much easier to tell your ISP "Sorry, ISP A, I've got a better price from ISP B and I'll move all my stuff if you don't beat their price." (Of course, customers like that are often telling ISP B "You'll have to be X% cheaper/faster/somethinger than ISP A or I'll just stay where I am" and telling ISP C "My main choices are ISP A and ISP B but I'd take a lowball quote very seriously...") -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
In message <18a5e7cb0910201638j7a24a10dwb8440a42f8f9c49e@mail.gmail.com>, Bill Stewart writes:
On Mon, Oct 19, 2009 at 7:07 PM, Nathan Ward <nanog@daork.net> wrote:
On 20/10/2009, at 3:02 PM, Bill Stewart wrote:
plus want the ability to take their address space with them when they change ISPs (because there are too many devices and applications that insist on having hard-coded IP addresses instead of using DNS, and because DNS tends to get cached more often than you'd sometimes like.
That's why we have Unique Local Addresses.
This is the opposite problem - ULAs are for internal devices, and what businesses often want is globally routable non-provider-owned public addresses. If you've got a VPN tunnel device, too often the remote end will want to contact you at some numerical IPv4 address and isn't smart enough to query DNS to get it.
Which just means we should be fixing the VPN box.
And even though most enterprises these days only use registered addresses outside the firewall and not inside the firewall, it's still a pain to have to renumber everything and wait for everybody's DNS caches to expire, so if you're using Provider-independent IP addresses, it's much easier to tell your ISP "Sorry, ISP A, I've got a better price from ISP B and I'll move all my stuff if you don't beat their price." (Of course, customers like that are often telling ISP B "You'll have to be X% cheaper/faster/somethinger than ISP A or I'll just stay where I am" and telling ISP C "My main choices are ISP A and ISP B but I'd take a lowball quote very seriously...")
Renumbering in IPv6 is not the same as renumbering in IPv4. IPv6 is designed to support multiple prefixes on the one interface. There is actually enough address space to support doing this and allow renumber events to take weeks or months if needed. There is no need to say at XX:XX on DD/MM/YYYY we will be switching prefixes. One can be much smarter about how you do it. You can just introduce the new prefix. Add second address to the DNS. Do your manual fixes. Remove the old addresses from the DNS. Stop using the old prefix when you are satisfied that there is no traffic over them.
-- ---- Thanks; Bill
Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
There is no need to say at XX:XX on DD/MM/YYYY we will be switching prefixes. One can be much smarter about how you do it.
You can just introduce the new prefix. Add second address to the DNS. Do your manual fixes. Remove the old addresses from the DNS. Stop using the old prefix when you are satisfied that there is no traffic over them.
True in principle. In practice, changing stuff, especially globally, is not as simple as that. Many (most?) enterprises still have pretty primitive DNS/DHCP management. While there are good management systems out there, many of the largest are custom made for the enterprise concerned, and are not yet up to speed with IPv6. The practical experience is not yet there to drive the development of the right features - especially ones as rare as a complete renumbering. DHCPv6 server software is still pretty early days, too. The addressing on infrastructure kit like routers and switches, firewalls and IDS boxes and so on is also typically hard coded and difficult to change, as are the addresses used in ACLs and firewall rules. Renumbering means: - adding a new AAAA record to the DNS for every existing AAAA record, but using a different prefix (plus any other DNS changes needed - like giving the servers themselves addresses in the new prefix, and making sure they reply from the right address...) Reverse lookups may be an issue during the changeover, too. - updating DHCP configurations to issue addresses from the new prefixes, automatically divided along the same numbering plan - setting up reserved DHCP addresses with the same host parts as the old reserved addresses but using the new prefix etc - adding new addresses to every location where an address is hardcoded - such as in router and switch configurations - updating ACLs to account for the new addresses (without discarding the old rules yet) - updating firewall rules and what-have-you to account for the new prefix, without discarding the old ones yet - waiting the weeks or months until the old prefix may be safely discarded. During this time you have a prefix-schizo network. - updating firewall rules and what-have-you to remove the old prefix - updating ACLs to remove the old addresses - removing old addresses from every location where an address is hardcoded - such as in router and switch configurations - removing now-unused DHCP reservations - removing now-unwanted DHCP ranges - removing all AAAA records that reference the old prefix ... and this is by no means an exhaustive list. Many higher-level services will also need updating (twice) - your web server configurations, for example. And it gets more complicated if your prefix changes length as well. And what if the network was not set up with future renumbering in mind? DHCP servers issuing eternal leases, things like that. So once again the theory is good, but reality intrudes. Renumbering, even with the undeniably much better features of IPv6, is still going to be a royal pain. Of course, IPv6 may drive improvements in all these areas over time, but they're not there yet. Wouldn't it be cool to have a "renumber router" command that just took an old prefix, a new prefix and a number of seconds and did all the work? Regards, K. PS: If anyone knows of an IPAM that can do all the above, or even just some of the above, please let me know! -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF
In message <1256085698.30246.109.camel@karl>, Karl Auer writes:
There is no need to say at XX:XX on DD/MM/YYYY we will be switching prefixes. One can be much smarter about how you do it. =20 You can just introduce the new prefix. Add second address to the DNS. Do your manual fixes. Remove the old addresses from the DNS. Stop using the old prefix when you are satisfied that there is no traffic over them.
True in principle. In practice, changing stuff, especially globally, is not as simple as that.
Many (most?) enterprises still have pretty primitive DNS/DHCP management. While there are good management systems out there, many of the largest are custom made for the enterprise concerned, and are not yet up to speed with IPv6. The practical experience is not yet there to drive the development of the right features - especially ones as rare as a complete renumbering.
DHCPv6 server software is still pretty early days, too.
The addressing on infrastructure kit like routers and switches, firewalls and IDS boxes and so on is also typically hard coded and difficult to change, as are the addresses used in ACLs and firewall rules.
Renumbering means:
- adding a new AAAA record to the DNS for every existing AAAA record, but using a different prefix (plus any other DNS changes needed - like giving the servers themselves addresses in the new prefix, and making sure they reply from the right address...) Reverse lookups may be an issue during the changeover, too.
- updating DHCP configurations to issue addresses from the new prefixes, automatically divided along the same numbering plan
- setting up reserved DHCP addresses with the same host parts as the old reserved addresses but using the new prefix etc
- adding new addresses to every location where an address is hardcoded - such as in router and switch configurations
- updating ACLs to account for the new addresses (without discarding the old rules yet)
- updating firewall rules and what-have-you to account for the new prefix, without discarding the old ones yet
- waiting the weeks or months until the old prefix may be safely discarded. During this time you have a prefix-schizo network.
- updating firewall rules and what-have-you to remove the old prefix
- updating ACLs to remove the old addresses
- removing old addresses from every location where an address is hardcoded - such as in router and switch configurations
- removing now-unused DHCP reservations
- removing now-unwanted DHCP ranges
- removing all AAAA records that reference the old prefix
... and this is by no means an exhaustive list. Many higher-level services will also need updating (twice) - your web server configurations, for example. And it gets more complicated if your prefix changes length as well. And what if the network was not set up with future renumbering in mind? DHCP servers issuing eternal leases, things like that.
So once again the theory is good, but reality intrudes. Renumbering, even with the undeniably much better features of IPv6, is still going to be a royal pain. Of course, IPv6 may drive improvements in all these areas over time, but they're not there yet.
Wouldn't it be cool to have a "renumber router" command that just took an old prefix, a new prefix and a number of seconds and did all the work?
Well request it from you favorite router vendors. Router/vpn/firewall vendors should be forced to renumber annually. That way they would have some incentive to make their products usable when a renumber event occurs. The same applies to other vendors.
Regards, K.
PS: If anyone knows of an IPAM that can do all the above, or even just some of the above, please let me know!
--=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob)
GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF
--=-lq/A/spfwZ9P7pLx73k/ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux)
iEYEABECAAYFAkreWLgACgkQSkRqA/Q6fe//UACfcPMTlaufxR4sk8pfJ9d7Uk/W rW4AmgNnotHOzM4DnvcT90ow+0kDxMVF =aZzD -----END PGP SIGNATURE-----
--=-lq/A/spfwZ9P7pLx73k/--
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Oct 20, 2009, at 8:41 PM, Karl Auer wrote:
In practice, changing stuff, especially globally, is not as simple as that.
From <http://tools.ietf.org/html/rfc4192>: 'Some took it on themselves to convince the authors that the concept of network renumbering as a normal or frequent procedure is daft.' ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Sorry, sometimes I mistake your existential crises for technical insights. -- xkcd #625
In message <1069DFD4-87A3-4E38-AEBC-43C05C16DECA@arbor.net>, Roland Dobbins wri tes:
On Oct 20, 2009, at 8:41 PM, Karl Auer wrote:
In practice, changing stuff, especially globally, is not as simple as that.
From <http://tools.ietf.org/html/rfc4192>:
'Some took it on themselves to convince the authors that the concept of network renumbering as a normal or frequent procedure is daft.'
There is a difference between renumbering every minute and renumber when required to optimise something else. We shouldn't be afraid to renumber. It should be something all vendors support. It should be as automated as possible. If there is a manual step you should be asking yourself "does this need to be done by hand". Remember there are lots of machines that renumber themselves several times a day as they move between work and home. All machines should be in a position to renumber themselves as easily as we renumber a laptop. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Oct 20, 2009, at 10:29 PM, Mark Andrews wrote:
Remember there are lots of machines that renumber themselves several times a day as they move between work and home
The problem isn't largely with the endpoints - it's with all the other devices/policies/etc. which overload the EID with inappropriate significance which tend to cause most of the problems. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Sorry, sometimes I mistake your existential crises for technical insights. -- xkcd #625
On Tue, Oct 20, 2009 at 10:15:39PM -0400, Roland Dobbins wrote:
On Oct 20, 2009, at 8:41 PM, Karl Auer wrote:
In practice, changing stuff, especially globally, is not as simple as that.
From <http://tools.ietf.org/html/rfc4192>:
'Some took it on themselves to convince the authors that the concept of network renumbering as a normal or frequent procedure is daft.'
We tried Fred's procedure some 4 years ago within 6NET: http://www.6net.org/publications/deliverables/D3.6.2.pdf The 'prefix schizo' actually worked out quite well. The routing changes and multi-refix links generally behaved as expected. Address selection did its thing. The basics worked as advertised. The complexity is of course not in the routing and hosts, it's as pointed out in the firewalls and similar devices (yours and more importantly other people's) for which new capabilities of IPv6 can't help. We captured some of these thoughts at the time in http://tools.ietf.org/html/draft-chown-v6ops-renumber-thinkabout-05 and since then Brian Carpenter has produced a much more up to date and rounded set of thoughts in http://tools.ietf.org/html/draft-carpenter-renum-needs-work-03 We're far from a magic button press. In smaller networks RFC4192 is workable, but the larger and more complex the network/site, there's still so many open issues that it's completely understandable the people will want PI. -- Tim
On Tue, 20 Oct 2009 19:38:58 -0400, Bill Stewart <nonobvious@gmail.com> wrote:
... If you've got a VPN tunnel device, too often the remote end will want to contact you at some numerical IPv4 address and isn't smart enough to query DNS to get it.
As I was told by Cisco, that's a security "feature". Fixed VPN endpoints are supposed to be *fixed* endpoints. Yes, it is a pain when an address changes, for whatever reason. But relying on DNS to eventually get the endpoint(s) right is an even bigger mess... how often is the name<->IP updated? how often do the various DNS servers revalidate those records? how often do the VPN devices revalidate the names? what happens when the dns changes while the vpn is still up? I'll stick with entering IP addresses. --Ricky
In message <op.u156b0mztfhldh@rbeam.xactional.com>, "Ricky Beam" writes:
On Tue, 20 Oct 2009 19:38:58 -0400, Bill Stewart <nonobvious@gmail.com> wrote:
... If you've got a VPN tunnel device, too often the remote end will want to contact you at some numerical IPv4 address and isn't smart enough to query DNS to get it.
As I was told by Cisco, that's a security "feature". Fixed VPN endpoints are supposed to be *fixed* endpoints. Yes, it is a pain when an address changes, for whatever reason. But relying on DNS to eventually get the endpoint(s) right is an even bigger mess... how often is the name<->IP updated?
It should be automatically updated by the end point. We do have the technology to do that.
how often do the various DNS servers revalidate those records?
If you are talking about caching servers then they will honour the TTL in the records.
how often do the VPN devices revalidate the names?
At startup. A well designed VPN protocol will support end point address mobility.
what happens when the dns changes while the vpn is still up?
This should be transparent to everything other than the vpn end points.
I'll stick with entering IP addresses.
--Ricky
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Doug Barton wrote:
Out of curiosity who is conducting this class and what was their rationale for using /127s?
It's a GK class. The instructor seems to be fairly knowledgeable and has a lengthy history consulting on and deploying IPv6. The class seems to be geared much more towards enterprise though instead of service providers. That's very unfortunate considering that every one of the 15 people in this class either works for or contracts to a SP. Still the instructor has some SP knowledge so he fills in the blanks when possible. We're all thinking like SPs though and we ask the SP-oriented questions which usually helps us steer the course the direction we want. I wish GK and other training companies would start offering classes geared towards SPs. They could easily take the existing courseware, add a couple days at the end and interject useful SP info into the earlier days. All that extra info could be specifically aimed at SPs. He didn't really give much of a reason for the /127s yet. I think it's coming up in a later session. I think it basically boiled down to whether or not the customer would actually use anything bigger. I'll write back when we get into that discussion. Justin
On 13/10/09 15:33, Justin Shore wrote:
He didn't really give much of a reason for the /127s yet. I think it's coming up in a later session. I think it basically boiled down to whether or not the customer would actually use anything bigger. I'll write back when we get into that discussion.
Anything other than /64 removes the possibility of using privacy (aka temporary) addresses, enabled on Vista and above by default (net.ipv6.conf.all.use_tempaddr on Linux). For a single prefix a host may have by default up to 8 global unicast addresses - 1 EUI-64 and 7 privacy.
He didn't really give much of a reason for the /127s yet. I think it's coming up in a later session. I think it basically boiled down to whether or not the customer would actually use anything bigger. I'll write back when we get into that discussion.
As a service provider, you do not have any control over the customer's environment. As a starter, that means sticking to the /64 per subnet boundary because you don't really know whether a customer might need some devices which assume EUI-64 interface addressing. But when you look at the source of your addresses, the RIRs, you will see that there policy allows for a /56 or a /48 to be assigned to residential customers, your choice. So, why would you want to use longer prefixes? Admittedly, in an enterprise environment where you have total control over the devices on the network, it may be reasonable to use /127s and other odd prefix lengths. But only if you actually have a reason. Not wasting addresses is not a reason, and any IPv6 architectural decisions driven by not wasting addresses, are not reasonable decisions. It is fundamental to IPv6 to use large address blocks that can never possibly be used up, in order to design a network where your design decisions are based on solid technical reasoning, and that design can remain unchanged even if you massively scale up the number of devices on your network. --Michael Dillon
So far, I have only dabbled with IPv6, but my reading of the RFCs is that VLSM for lengths beyond /64 is not required. Subsequently, to use anything longer is an enormous gamble in an enterprise environment. I envision upgrading code one day and finding that your /127 isn't supported any more and they forgot to mention it. I'll stick to /64, though it does seem a horrible waste of space. Someone else might have read the RFC differently though. Eric Clark
eric clark wrote:
So far, I have only dabbled with IPv6, but my reading of the RFCs is that VLSM for lengths beyond /64 is not required. Subsequently, to use anything longer is an enormous gamble in an enterprise environment. I envision upgrading code one day and finding that your /127 isn't supported any more and they forgot to mention it. I'll stick to /64, though it does seem a horrible waste of space.
Someone else might have read the RFC differently though.
I'm sure there's an RFC somewhere talking about Classful addressing pre-CIDR. Perhaps we should stop using CIDR in IPv4. It might stop working one day. ;) Operational reality helps to refine RFCs. Many people are already using longer prefixes for infrastructure and other purposes, so it's unlikely to go away. The only real issue is that some old hardware may not support prefixes longer than /64 in hardware and so may drop to software routing. I don't know of any examples of this though. adam.
While entirely possible, I actually view it going the other way. RFC 3627 points out some nice issues as far as DAD and anycast operation is concerned, but what I'd see (just my random opinion as I haven't bothered to write an RFC) is that it would make entirely much more sense to come up with a structure to STOP the anycast performance on a link that is point-to-point. While there are 340 undecillion addresses, that doesn't mean we need to waste a /64 on a link that will possibly only have two addresses anyway. My two cents. Scott eric clark wrote:
So far, I have only dabbled with IPv6, but my reading of the RFCs is that VLSM for lengths beyond /64 is not required. Subsequently, to use anything longer is an enormous gamble in an enterprise environment. I envision upgrading code one day and finding that your /127 isn't supported any more and they forgot to mention it. I'll stick to /64, though it does seem a horrible waste of space.
Someone else might have read the RFC differently though.
Eric Clark
On Tue, 13 Oct 2009 09:33:03 -0400, Justin Shore <justin@justinshore.com> wrote:
He didn't really give much of a reason for the /127s yet. I think it's coming up in a later session. I think it basically boiled down to whether or not the customer would actually use anything bigger. I'll write back when we get into that discussion.
It's the IPv6 equiv of an IPv4 /30 link network. Then a /64 or whatever can be aimed to that link address. This is exactly what Bellsouth does for business DSL: the link has a dynamic address and your netblock is then routed to it. (this is confusing and unworkable for a lot of cheap hardware.)
In message <op.u1rnahbbtfhldh@rbeam.xactional.com>, "Ricky Beam" writes:
On Tue, 13 Oct 2009 09:33:03 -0400, Justin Shore <justin@justinshore.com> wrote:
He didn't really give much of a reason for the /127s yet. I think it's coming up in a later session. I think it basically boiled down to whether or not the customer would actually use anything bigger. I'll write back when we get into that discussion.
It's the IPv6 equiv of an IPv4 /30 link network. Then a /64 or whatever can be aimed to that link address. This is exactly what Bellsouth does for business DSL: the link has a dynamic address and your netblock is then routed to it. (this is confusing and unworkable for a lot of cheap hardware.)
Just use a /64 for the customer link. That allows them to have a CGA if they need one. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
-----Original Message----- From: Justin To go along with Dan's query from above, what are the preferred methods that other SPs are using to deploy IPv6 with non-IPv6-capable edge hardware? We too have a very limited number of dialup customers and will never sink another dollar in the product. Unfortunately I also have brand-new ADSL2+ hardware that doesn't support IPv6 and according to the vendors (Pannaway) never will. We also have CMTSs that don't support IPv6, even though they too are brand-new. Those CMTSs top out at DOCSIS 2.0 and the vendor decided not to allow IPv6 to the CPEs regardless of the underlying CM's IPv6 support or lack thereof (like Cisco allowed for example). Are providers implementing tunneling solutions? Pros/cons of the various solutions?
My first (potentially ignorant) response would be to get your acquisitions
people aligned with your business, and by that I mean they should be making a concerted effort to only buy IPv6 capable gear, especially when IPv6 is
coming to you within that gears lifecycle. I guess your customers will need to tunnel, as long as you give them a public IP they have 6to4 (and possibly Teredo, tunnel broker) - but native is better.
Nathan Ward, please stand up. Adrian On Tue, Oct 13, 2009, TJ wrote:
-----Original Message----- From: Justin To go along with Dan's query from above, what are the preferred methods that other SPs are using to deploy IPv6 with non-IPv6-capable edge hardware? We too have a very limited number of dialup customers and will never sink another dollar in the product. Unfortunately I also have brand-new ADSL2+ hardware that doesn't support IPv6 and according to the vendors (Pannaway) never will. We also have CMTSs that don't support IPv6, even though they too are brand-new. Those CMTSs top out at DOCSIS 2.0 and the vendor decided not to allow IPv6 to the CPEs regardless of the underlying CM's IPv6 support or lack thereof (like Cisco allowed for example). Are providers implementing tunneling solutions? Pros/cons of the various solutions?
My first (potentially ignorant) response would be to get your acquisitions
people aligned with your business, and by that I mean they should be making a concerted effort to only buy IPv6 capable gear, especially when IPv6 is
coming to you within that gears lifecycle. I guess your customers will need to tunnel, as long as you give them a public IP they have 6to4 (and possibly Teredo, tunnel broker) - but native is better.
-- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA -
Ok, I've decided to do this a different way to my usual ranting. Instead of explaining the options over and over and hoping people can make sense of the complexities of it, become experts, and make good informed decisions, I've made a flow chart. Feel free to ask about details and I can get in to the ranting part, this is really a place to start. Right now it assumes people only provide DSL or other dynamic sort of services. It also assumes DS-Lite people are insane, so probably need better language there. Also the first question is not necessarily about who you are, but who is driving the IPv6 'build' - which is why native, 6rd and ds-lite are not appropriate for the customer-driven side. I hope that makes sense. No talk about ISATAP and stuff for inside the customer network either. And before you ask no ISATAP is not appropriate for ISPs, doesn't work through NAT. Anyway: - 6RD is used by free.fr. Not widely implemented by anyone yet. - DS-Lite is something some guys at Comcast and others are talking about. Not widely implemented by anyone yet. - The rest you can figure out from wikipedia and stuff. Please email me with any corrections, complaints, or threats if you're a DS-Lite fan. I'll always keep old versions in this directory, and the latest version will always have this filename, so please link to it instead of copying it, etc. etc.: http://www.braintrust.co.nz/resources/ipv6_flow_chart/ipv6_flow_chart-curren... On 13/10/2009, at 11:26 PM, Adrian Chadd wrote:
Nathan Ward, please stand up.
Adrian
On Tue, Oct 13, 2009, TJ wrote:
-----Original Message----- From: Justin To go along with Dan's query from above, what are the preferred methods that other SPs are using to deploy IPv6 with non-IPv6-capable edge hardware? We too have a very limited number of dialup customers and will never sink another dollar in the product. Unfortunately I also have brand-new ADSL2+ hardware that doesn't support IPv6 and according to the vendors (Pannaway) never will. We also have CMTSs that don't support IPv6, even though they too are brand-new. Those CMTSs top out at DOCSIS 2.0 and the vendor decided not to allow IPv6 to the CPEs regardless of the underlying CM's IPv6 support or lack thereof (like Cisco allowed for example). Are providers implementing tunneling solutions? Pros/cons of the various solutions?
My first (potentially ignorant) response would be to get your acquisitions
people aligned with your business, and by that I mean they should be making a concerted effort to only buy IPv6 capable gear, especially when IPv6 is
coming to you within that gears lifecycle. I guess your customers will need to tunnel, as long as you give them a public IP they have 6to4 (and possibly Teredo, tunnel broker) - but native is better.
-- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA -
!DSPAM:22,4ad455ce140151847938845!
In message <EECC7B21-7390-446B-B54F-48D92AB889C7@daork.net>, Nathan Ward writes:
Ok, I've decided to do this a different way to my usual ranting. Instead of explaining the options over and over and hoping people can make sense of the complexities of it, become experts, and make good informed decisions, I've made a flow chart. Feel free to ask about details and I can get in to the ranting part, this is really a place to start.
Right now it assumes people only provide DSL or other dynamic sort of services. It also assumes DS-Lite people are insane, so probably need better language there.
DS-Lite is there for when the ISP runs out of IPv4 addresses to hand one to each customer. Many customers don't need a unique IPv4 address, these are the ones you switch to DS-Lite. Those that do require a unique IPv4 you leave on full dual stack for as long as you can. You forgot the tunnel brokers.
Also the first question is not necessarily about who you are, but who is driving the IPv6 'build' - which is why native, 6rd and ds-lite are not appropriate for the customer-driven side. I hope that makes sense. No talk about ISATAP and stuff for inside the customer network either. And before you ask no ISATAP is not appropriate for ISPs, doesn't work through NAT.
Anyway: - 6RD is used by free.fr. Not widely implemented by anyone yet. - DS-Lite is something some guys at Comcast and others are talking about. Not widely implemented by anyone yet. - The rest you can figure out from wikipedia and stuff.
Please email me with any corrections, complaints, or threats if you're a DS-Lite fan. I'll always keep old versions in this directory, and the latest version will always have this filename, so please link to it instead of copying it, etc. etc.:
http://www.braintrust.co.nz/resources/ipv6_flow_chart/ipv6_flow_chart-curren... -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 14/10/2009, at 7:23 PM, Mark Andrews wrote:
DS-Lite is there for when the ISP runs out of IPv4 addresses to hand one to each customer. Many customers don't need a unique IPv4 address, these are the ones you switch to DS-Lite. Those that do require a unique IPv4 you leave on full dual stack for as long as you can. The authors of DS-lite say it's because running a dual stack network is hard.
You clearly don't share that view , so in your view what's wrong with dual stack with IPv4for everyone then, whether they need a unique address or not? DS-lite requires CGN, so does dual stack without enough IPv4 addresses. This is probably the wrong forum for a DS-lite debate. I'm sure people have a use for it, they actually might have gear that can only do IPv4 OR IPv6 but not both or something. My problem with it is that it's being seen as a solution for a whole lot of people, when in reality it's a solution for a small number of people. Thanks for the point about the tunnel brokers though, I missed that, I'll update this tomorrow with any suggestions I get before then. -- Nathan Ward
In message <E752070A-9081-4B36-8FB9-F60E0E420F88@daork.net>, Nathan Ward writes :
On 14/10/2009, at 7:23 PM, Mark Andrews wrote:
DS-Lite is there for when the ISP runs out of IPv4 addresses to hand one to each customer. Many customers don't need a unique IPv4 address, these are the ones you switch to DS-Lite. Those that do require a unique IPv4 you leave on full dual stack for as long as you can.
The authors of DS-lite say it's because running a dual stack network is hard.
It is harder.
You clearly don't share that view, so in your view what's wrong with dual stack with IPv4 for everyone then, whether they need a unique address or not?
Dual stack for everyone was feasible 5 years ago. It isn't anymore, that transition plan has sailed and almost no one got on board. Because there aren't enough addresses to go around and there hasn't been for years. PNAT is a kludge to work around that fact. When you can't give every customer their own IPv4 address yet you still need to provide IPv4 connectivity you need to work out how to share those addresses you have efficiently. Given double PNAT or DS-Lite I know which one I prefer. DS-Lite allows lots of the tricks used with PNAT to continue to work. Those tricks will just stop working with double PNAT.
DS-lite requires CGN, so does dual stack without enough IPv4 addresses.
This is probably the wrong forum for a DS-lite debate. I'm sure people have a use for it, they actually might have gear that can only do IPv4 OR IPv6 but not both or something. My problem with it is that it's being seen as a solution for a whole lot of people, when in reality it's a solution for a small number of people.
It's not the only solution. There are others and customers and ISP's will need to work out what is best for their collective requirements. It is a reasonable fit for residentual ISP's as the CPE PNAT is really very inefficient at conserving addresses and by splitting the PNAT across 2 co-operating boxes you can get the address utilisation efficency we now need in IPv4 to cover all the short sightedness that has got us to the place where we need things other than dual stack.
Thanks for the point about the tunnel brokers though, I missed that, I'll update this tomorrow with any suggestions I get before then.
-- Nathan Ward -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 12/10/09 21:34 -0500, Justin Shore wrote:
To go along with Dan's query from above, what are the preferred methods that other SPs are using to deploy IPv6 with non-IPv6-capable edge hardware? We too have a very limited number of dialup customers and will never sink another dollar in the product. Unfortunately I also have brand-new ADSL2+ hardware that doesn't support IPv6 and according to the vendors (Pannaway) never will.
I don't recall if Pannaway is a layer 3 or layer 2 DSLAM, but we have a mix of Calix C7 (ATM) and Calix E5 (Ethernet) gear in our network. We're kinda in the same boat, but we expect to be able to gracefully transition to dual stacked IPv4/IPv6 without having to replace DSL modems, by reconfiguring the modems into bridged mode and leaving the layer 3 up to the customer's router. We're also in the process of budgeting for a new broadband aggregation router next year that will handle IPv6. Ask Pannaway if they can bridge traffic (either ATM PVC, or Ethernet QinQ/VLAN per subscriber) up to a broadband aggregator, like a Redback or Cisco. -- Dan White
Dan White wrote:
I don't recall if Pannaway is a layer 3 or layer 2 DSLAM, but we have a mix of Calix C7 (ATM) and Calix E5 (Ethernet) gear in our network. We're kinda in the same boat, but we expect to be able to gracefully transition to dual stacked IPv4/IPv6 without having to replace DSL modems, by reconfiguring the modems into bridged mode and leaving the layer 3 up to the customer's router.
We're also in the process of budgeting for a new broadband aggregation router next year that will handle IPv6. Ask Pannaway if they can bridge traffic (either ATM PVC, or Ethernet QinQ/VLAN per subscriber) up to a broadband aggregator, like a Redback or Cisco.
In Pannaway's case they want to pretend to be in the router business and we ended up buying their BARs. Their DSLAMs (BASs) are aggregated into their BARs and the BAR ring terminates on my Cisco core. I would love to eliminate the BARs from the equation but that's not an option. I've been by several (dozen) people that their Minnesota Pannaway office stopped selling the BARs and instead worked with Cisco for aggregation. I've also been told by Cisco folks that numerous sites are trying to get Cisco to take the Pannaway BARs in on trade-in. It would appear that no one like the BARs. Occam did it right. They didn't try to pretend to be in the router business. They stuck with L2. We're also in a bit of a pickle because we're using "smart" DSL modems/routers. I've argued for years for dumb DSL modems that had no routing/NAT capabilities at all. Unfortunately I didn't win that argument. Now we have what amount to CPEs that do not support IPv6. Whether they'll even pass IPv6 packets in a bridging mode is yet to be determined. Since some of the modems are Pannaway and given my experience with Pannaway and trying to bridge things over it without Pannaway messing with it in the middle (VLAN carrying IS-IS for example), I fully expect problems... It's no secret; I do not recommend Pannaway products based on my firsthand experience. Their SE actually told us 2 years ago that IPv6 was a fad and would never be adopted. Justin
On 13/10/09 15:32 -0500, Justin Shore wrote:
one like the BARs. Occam did it right. They didn't try to pretend to be in the router business. They stuck with L2.
Occam did it partially right. They're half-bridging only - not true layer 2 to an aggregator (which is not necessary in their scenario). The problem with the access vendor doing half-bridging is that they have to be very layer-3 smart, and Occam was not quite there for IPv6 last time I worked with them (about 6 months ago).
It's no secret; I do not recommend Pannaway products based on my firsthand experience. Their SE actually told us 2 years ago that IPv6 was a fad and would never be adopted.
I haven't really been happy with any DSL vendor's response to my questions about IPv6. We happened to choose Calix, which is not particularly IPv6 friendly, but were successful in getting commitments from them to support IPv6 pass through. I have little doubt that Pannaway could implement IPv6, they just need to get enough demand from customers to make it worth their while. -- Dan White
Dan White wrote:
Occam did it partially right. They're half-bridging only - not true layer 2 to an aggregator (which is not necessary in their scenario). The problem with the access vendor doing half-bridging is that they have to be very layer-3 smart, and Occam was not quite there for IPv6 last time I worked with them (about 6 months ago).
When we did a RFP with them they didn't support v6 yet but they also wouldn't get in the way of passing v6 over them (minus the DHCP snooping/learning features of course). That was 2 years ago. I haven't looked at them since but they said that they'd work on it.
I haven't really been happy with any DSL vendor's response to my questions about IPv6. We happened to choose Calix, which is not particularly IPv6 friendly, but were successful in getting commitments from them to support IPv6 pass through.
None of the FTTH vendors we vetted supported v6 but at least a few said that they'd work on it. Pannaway's response though was priceless.
I have little doubt that Pannaway could implement IPv6, they just need to get enough demand from customers to make it worth their while.
Pannaway was bought a while back by Enablence. Hopefully they will drive a bit more clue into the products. Hopefully that SE isn't there anymore or if he is hopefully he's not driving product development. His other 2 answers about QoS not being needed because our links were sustaining saturation (microbursts anyone?) and that we didn't need an IGP because our network wasn't big enough and that static routing would do (for just shy of 100 routing devices in 3 POPs) was the icing on the cake. Unfortunately the decision was made to eat the cake anyway. Justin
So you're saying moving away from PPPoA/E and just going bridged? Frank -----Original Message----- From: Dan White [mailto:dwhite@olp.net] Sent: Tuesday, October 13, 2009 9:15 AM To: Justin Shore Cc: nanog@nanog.org Subject: Re: ISP customer assignments On 12/10/09 21:34 -0500, Justin Shore wrote:
To go along with Dan's query from above, what are the preferred methods that other SPs are using to deploy IPv6 with non-IPv6-capable edge hardware? We too have a very limited number of dialup customers and will never sink another dollar in the product. Unfortunately I also have brand-new ADSL2+ hardware that doesn't support IPv6 and according to the vendors (Pannaway) never will.
I don't recall if Pannaway is a layer 3 or layer 2 DSLAM, but we have a mix of Calix C7 (ATM) and Calix E5 (Ethernet) gear in our network. We're kinda in the same boat, but we expect to be able to gracefully transition to dual stacked IPv4/IPv6 without having to replace DSL modems, by reconfiguring the modems into bridged mode and leaving the layer 3 up to the customer's router. We're also in the process of budgeting for a new broadband aggregation router next year that will handle IPv6. Ask Pannaway if they can bridge traffic (either ATM PVC, or Ethernet QinQ/VLAN per subscriber) up to a broadband aggregator, like a Redback or Cisco. -- Dan White
I can't offer any knowledgeable advice about PPPoA/E. We have never used it ourselves. On 14/10/09 22:16 -0500, Frank Bulk wrote:
So you're saying moving away from PPPoA/E and just going bridged?
Frank
-----Original Message----- From: Dan White [mailto:dwhite@olp.net]
Ask Pannaway if they can bridge traffic (either ATM PVC, or Ethernet QinQ/VLAN per subscriber) up to a broadband aggregator, like a Redback or Cisco.
-- Dan White
-----Original Message----- From: Robert.E.VanOrmer@frb.gov [mailto:Robert.E.VanOrmer@frb.gov] Sent: Monday, October 05, 2009 7:41 PM To: nanog@nanog.org Subject: Re: ISP customer assignments
The address space is daunting in scale as you have noted, but I don't see any lessons learned in address allocation between IPv6 and IPv4. Consider as a residential customer, I will be provided a /64, which means each individual on Earth will have roughly 1 billion addresses each.
Organizations will be provided /48s or smaller, but given the current issues with routing /48's globally, I think you will find more organizations fighting for /32s or smaller... so what once was a astonomical number of addresses
Nope. You should get a ~/56. Even so, a /64 gives you ~18BillionBillion addresses. that
one cannot concieve numerically, soon becomes much smaller. I can see an IPv7
Nope, organizations will go for PI ~/48s, and Verizon will be forced to stop filtering them. Oh, and IIRC - as it stands now, IPv7-9 are already shot (similar to IPv1-3) ... so IPv10 would be next up, in a century ... or four.
in the future, and doing it all over again... I just hope I retire before it comes... The only difference I can see between IPv4 and IPv6 is how much of a
pain it is to type a 128 bit address... Just like back in the day when Class B networks were handed out like candy, one day we will be figuring out how to
Are you retiring in the next 0-3 years? :) put
in emergency allocations on the ARIN listserv for IPv6 because of address exhaustion and waste.
As for the lessons learned - it is about scale. 32 bits isn't enough, double it 96 more times (or 32 more times for just the network side, if you prefer) and it is enough. /TJ
On Mon, Oct 5, 2009 at 7:41 PM, <Robert.E.VanOrmer@frb.gov> wrote:
The address space is daunting in scale as you have noted, but I don't see any lessons learned in address allocation between IPv6 and IPv4.
Robert, I would suggest that some of the lessons we learned are faulty. Maladaptive. CIDR for instance. In a classful world, folks who needed a class A got a class A and were able to announce a class A. They couldn't announce 4200 little divisions of their addresses like Bell South on last Friday's CIDR report. CIDR made today's BGP mess possible. With a larger address space, let's say 128 bits, things *could* have been partitioned in a such a way that there were enough class B's for everyone who needed more than a class C and plenty of class-A's for everyone who needed more than a class B. There's no doubt that CIDR saved the Internet. There -weren't- enough IPv4 class B's for everyone who needed more than a class C. CIDR made it possible to express ranges of class C's as a single route and that's just the start. But CIDR also created today's problems where it isn't possible to tell the difference between a route that represents a unique multihomed endpoint and routes which reflect nothing more than a bad actor making you pay his traffic engineering cost. So now Verizon is in open revolt against ARIN. They positively refuse to carry /48's from legitimately multihomed users. Eff 'em. Perhaps Verizon would sooner see IPv6 go down in flames than see their TCAMs fill up again. Who knows their reasoning? Agree or disagree, it is indeed food for thought. One thing I can say with confidence: as a community we truly haven't grasped the major implications of an address space that isn't scarce coupled with a routing table that is. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
So now Verizon is in open revolt against ARIN. They positively refuse to carry /48's from legitimately multihomed users. Eff 'em. Perhaps Verizon would sooner see IPv6 go down in flames than see their TCAMs fill up again. Who knows their reasoning?
Agree or disagree, it is indeed food for thought. One thing I can say with confidence: as a community we truly haven't grasped the major implications of an address space that isn't scarce coupled with a routing table that is.
Thing is, I'm an end user site. I need more that a /48, but probably less than a /32. Seeing as how we have an AS and PI, PA isn't going to cut it. What am I supposed to do? ARIN suggested creative subnetting. We pushed back and got a /41. If IPv6 doesn't scratch an itch, why bother? There are plenty of high-profile end user sites in 2620::/23. Some government (CIA), some popular (Facebook.) I don't think Verizon's stand is going to last. Tim:>
Tim Durack wrote:
Thing is, I'm an end user site. I need more that a /48, but probably less than a /32. Seeing as how we have an AS and PI, PA isn't going to cut it. What am I supposed to do? ARIN suggested creative subnetting. We pushed back and got a /41. If IPv6 doesn't scratch an itch, why bother?
We were assigned a /43. insofar as I can tell that's Arin policy working just fine.
There are plenty of high-profile end user sites in 2620::/23. Some government (CIA), some popular (Facebook.) I don't think Verizon's stand is going to last.
Tim:>
joel jaeggli wrote:
Tim Durack wrote:
Thing is, I'm an end user site. I need more that a /48, but probably less than a /32. Seeing as how we have an AS and PI, PA isn't going to cut it. What am I supposed to do? ARIN suggested creative subnetting. We pushed back and got a /41. If IPv6 doesn't scratch an itch, why bother?
We were assigned a /43. insofar as I can tell that's Arin policy working just fine.
Mind if I ask what is is so I can see if it's in my Verizon table? Offlist is fine, I can just post yea/nea to the list. ~Seth
-----Original Message----- From: Robert.E.VanOrmer@frb.gov [mailto:Robert.E.VanOrmer@frb.gov] Sent: Monday, October 05, 2009 7:41 PM To: nanog@nanog.org Subject: Re: ISP customer assignments
Organizations will be provided /48s or smaller, but given the current issues with routing /48's globally, I think you will find more organizations fighting for /32s or smaller...
Most organizations will still be assigned a /48 (or whatever) from their ISP. Provider-aggregable addressing has no routing scalability problems.
I can see between IPv4 and IPv6 is how much of a pain it is to type a 128 bit address...
I have to agree, here. Moving between letters and numbers, and having to hit "shift" to use the colon wastes valuable keystrokes compared to the keypad. However, compare IPv6 vs IPv4-like numbering: 2001:db8:f1::1 81.93.35.12.241.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1 Did I type the right number of zeroes? Lee
On Oct 6, 2009, at 7:29 AM, Lee Howard wrote:
-----Original Message----- From: Robert.E.VanOrmer@frb.gov [mailto:Robert.E.VanOrmer@frb.gov] Sent: Monday, October 05, 2009 7:41 PM To: nanog@nanog.org Subject: Re: ISP customer assignments
Organizations will be provided /48s or smaller, but given the current issues with routing /48's globally, I think you will find more organizations fighting for /32s or smaller...
Most organizations will still be assigned a /48 (or whatever) from their ISP. Provider-aggregable addressing has no routing scalability problems.
I can see between IPv4 and IPv6 is how much of a pain it is to type a 128 bit address...
I have to agree, here. Moving between letters and numbers, and having to hit "shift" to use the colon wastes valuable keystrokes compared to the keypad. However, compare IPv6 vs IPv4-like numbering:
2001:db8:f1::1 81.93.35.12.241.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1
Did I type the right number of zeroes?
I don't know, but, it's not 81.93.35.12... It's: 32.1.13.184.241.0.0.0.0.0.0.0.0.0.0.1 And that is the correct number of zeroes for 2001:db8:f1::1. Also, there's no reason the syntax couldn't be made 32.1.13.184.241..1 although that isn't the case today. However, I believe that 90.1 is supposed to be parsed equivalent to 90.0.0.1 and 90.5.1 is supposed to be treated as 90.5.0.1, so, 32.1.13.184.241.1 should also work for the above if you expanded todays IPv4 notation to accept IPv6 length addresses. Owen
Lee
On Tue, 06 Oct 2009 09:34:28 PDT, Owen DeLong said:
although that isn't the case today. However, I believe that 90.1 is supposed to be parsed equivalent to 90.0.0.1 and 90.5.1 is supposed to be treated as 90.5.0.1, so, 32.1.13.184.241.1 should also work for the above if you expanded todays IPv4 notation to accept IPv6 length addresses.
So if you expand the notation like that, is 32.1.13.7 a 32 bit IPv4 address, or a 128 bit IPv6 address with lots of zeros between 13 and 7? They chose the ":" instead of overloading '.' for a *reason*...
participants (56)
-
Adam Armstrong -
Adrian Chadd -
Antonio Querubin -
Bill Stewart -
Bjørn Mork -
bmanning＠vacation.karoshi.com -
Brian Johnson -
Chris Adams -
Chris Hills -
Cord MacLeod -
Curtis Maurand -
Dan White -
Daniel Golding -
Dave Temkin -
David Andersen -
David Barak -
David Conrad -
Doug Barton -
eric clark -
Frank Bulk -
George Michaelson -
James Hess -
James R. Cutler -
Joe Abley -
Joe Greco -
joel jaeggli -
Joel Jaeggli
-
John Kristoff -
Justin Shore -
Karl Auer -
Kevin Loch -
Lee Howard -
Leo Bicknell -
Marco Hogewoning -
Mark Andrews -
Mark Newton -
Mark Smith -
Matthew Petach -
Michael Dillon -
Michael Thomas -
Nathan Ward -
Owen DeLong -
Ricky Beam -
Rob Evans -
Robert.E.VanOrmer＠frb.gov -
Roland Dobbins -
Scott Morris -
Seth Mattinen -
Tim Chown -
Tim Durack -
TJ -
Tore Anderson -
Valdis.Kletnieks＠vt.edu -
Walter Keen -
William Herrin -
Wouter de Jong