RE: Private use of non-RFC1918 IP space
Michael Hallgren <m.hallgren@free.fr>:
Really really LARGE scalability testing that needs more addresses than RFC1918 gives you.
Use IPv6.
For an IPv4 scalability test? Interesting idea... Apart from the basic incompability here, my opinion of IPv6 is that it just gives you 2^96 more addresses to repeat all the old mistakes with. --Johnny
On Mon, 02 Feb 2009 23:17:23 GMT, Johnny Eriksson said:
Michael Hallgren <m.hallgren@free.fr>:
Really really LARGE scalability testing that needs more addresses than RFC1918 gives you.
Use IPv6.
For an IPv4 scalability test? Interesting idea...
Might wanna consider that if you're doing a scalability *test* that burns over a /8 of IPv4, how do you intend to *deploy* the sucker? Gonna be a bear trying to get a /8 or 3 allocated when The Final Days are upon us already...
Le lundi 02 février 2009 à 23:17 +0000, Johnny Eriksson a écrit :
Michael Hallgren <m.hallgren@free.fr>:
Really really LARGE scalability testing that needs more addresses than RFC1918 gives you.
Use IPv6.
For an IPv4 scalability test? Interesting idea...
Plaisanterie of sorts... But off "plaisanterie," I ref. the statement above.
Apart from the basic incompability here, my opinion of IPv6 is that it just gives you 2^96 more addresses to repeat all the old mistakes with.
Some mistakes, sure; not all. Keep the multihoming game in mind, for instance. Sure is that misuse is much possible also in the IPv6 space! Cheers, mh
--Johnny
-- michael hallgren, mh2198-ripe
On 3/02/2009, at 12:17 PM, Johnny Eriksson wrote:
Michael Hallgren <m.hallgren@free.fr>:
Really really LARGE scalability testing that needs more addresses than RFC1918 gives you.
Use IPv6.
For an IPv4 scalability test? Interesting idea...
Apart from the basic incompability here, my opinion of IPv6 is that it just gives you 2^96 more addresses to repeat all the old mistakes with.
Not quite.. 2^96 = 79228162514264337593543950336 2^128-2^32 = 340282366920938463463374607427473244160 -- Nathan Ward
Apart from the basic incompability here, my opinion of IPv6 is that it just gives you 2^96 more addresses to repeat all the old mistakes with. Not quite.. 2^96 = 79228162514264337593543950336 2^128-2^32 = 340282366920938463463374607427473244160
not quite. let's posit 42 devices on the average lan segment (ymmv). 42*(2^64) = 774763251095801167872 randy
On Tue, 03 Feb 2009 11:25:40 +0900, Randy Bush said:
Apart from the basic incompability here, my opinion of IPv6 is that it just gives you 2^96 more addresses to repeat all the old mistakes with. Not quite.. 2^96 = 79228162514264337593543950336 2^128-2^32 = 340282366920938463463374607427473244160
not quite. let's posit 42 devices on the average lan segment (ymmv).
42*(2^64) = 774763251095801167872
Let's face it - they're going to have to come up with much more creative $200/hour chucklehead consultants to burn through that much anytime soon. Of course, I've long suspected that the 90% of the universe that's "dark matter" is all contained inside the craniums of all those chucklehead consultants (which is why they're so resistant to interactions with cluons from the rest of reality), so there's unfortunately a definite growth potential there... Anybody feel like starting a pool for when we'll see a posting to NANOG about somebody who's managed to burn through a /32?
Let's face it - they're going to have to come up with much more creative $200/hour chucklehead consultants to burn through that much anytime soon.
It has been my experience that when you give someone a huge address space to play with (eg 10/8), they start doing things like using bits in the address as flags for things. Suddenly you find yourself using a prefix that should enough for a decent sized country in a half-rack. It's only slightly harder to imagine a /48 being wasted like that. -Anthony
On Feb 3, 2009, at 12:30 AM, Anthony Roberts wrote:
Let's face it - they're going to have to come up with much more creative $200/hour chucklehead consultants to burn through that much anytime soon.
It has been my experience that when you give someone a huge address space to play with (eg 10/8), they start doing things like using bits in the address as flags for things. Suddenly you find yourself using a prefix that should enough for a decent sized country in a half-rack.
It's only slightly harder to imagine a /48 being wasted like that.
Except the RIRs won't give you another /48 when you have only used one trillion IP addresses. -- TTFN, patrick
In message <ADE1A7A6-7177-4C77-8023-60058FDF076B@ianai.net>, "Patrick W. Gilmor e" writes:
On Feb 3, 2009, at 12:30 AM, Anthony Roberts wrote:
Let's face it - they're going to have to come up with much more creative $200/hour chucklehead consultants to burn through that much anytime soon.
It has been my experience that when you give someone a huge address space to play with (eg 10/8), they start doing things like using bits in the address as flags for things. Suddenly you find yourself using a prefix that should enough for a decent sized country in a half-rack.
It's only slightly harder to imagine a /48 being wasted like that.
Except the RIRs won't give you another /48 when you have only used one trillion IP addresses.
-- TTFN, patrick
But they will when you will exceeded 65536 networks. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
On Feb 3, 2009, at 12:39 AM, Mark Andrews wrote:
In message <ADE1A7A6-7177-4C77-8023-60058FDF076B@ianai.net>, "Patrick W. Gilmor e" writes:
On Feb 3, 2009, at 12:30 AM, Anthony Roberts wrote:
Let's face it - they're going to have to come up with much more creative $200/hour chucklehead consultants to burn through that much anytime soon.
It has been my experience that when you give someone a huge address space to play with (eg 10/8), they start doing things like using bits in the address as flags for things. Suddenly you find yourself using a prefix that should enough for a decent sized country in a half-rack.
It's only slightly harder to imagine a /48 being wasted like that.
Except the RIRs won't give you another /48 when you have only used one trillion IP addresses.
-- TTFN, patrick
But they will when you will exceeded 65536 networks.
Which is exactly what they should do - actually before that one would hope. This is not the "$200/hour chcklehead consultant"'s fault, that is the design. Don't you love the idea of using 18446744073709551616 IP addresses to number a point-to-point link? -- TTFN, patrick
Which is exactly what they should do - actually before that one would hope. This is not the "$200/hour chcklehead consultant"'s fault, that is the design.
Don't you love the idea of using 18446744073709551616 IP addresses to number a point-to-point link?
Let's not ignore that all IPv6 allocations are basically charged-for, so my expectation is that there will be fewer "idle" allocations that can't be recovered running around (when an org has to justify $36,000 per year [after 2012], forever, some bean counter may ask why... especially if they can get a "sensibly" sized allocation from their provider for a fraction of that cost). I'm not sure if that is cynical, or optimistic, but since the allocations are not free, there seems to be less incentive to squat. Deepak Jain AiNET
Patrick W. Gilmore wrote:
Except the RIRs won't give you another /48 when you have only used one trillion IP addresses.
Are you sure? According to ARIN staff, current implementation of policy is that all requests are approved since there are no defined criteria that would allow them to deny any. So far, nobody's shown interest in plugging that hole in the policy because it'd be a major step forward if IPv6 were popular enough for anyone to bother wasting it... S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
On Feb 3, 2009, at 1:01 AM, Stephen Sprunk wrote:
Patrick W. Gilmore wrote:
Except the RIRs won't give you another /48 when you have only used one trillion IP addresses.
Are you sure? According to ARIN staff, current implementation of policy is that all requests are approved since there are no defined criteria that would allow them to deny any. So far, nobody's shown interest in plugging that hole in the policy because it'd be a major step forward if IPv6 were popular enough for anyone to bother wasting it...
Touché. I assumed if you had an allocation and came back for a second, they would say no. Hrmm, time for me to go get another (or another 1000?) v6 allocations. :) -- TTFN, patrick
Thanks all for the input. Cheers, --Trey ++----------------------------------------------------------------------------++ Kingfisher Operations Trey Darley - Principal
Stephen Sprunk wrote:
Patrick W. Gilmore wrote:
Except the RIRs won't give you another /48 when you have only used one trillion IP addresses.
Keyword: *Another*
Are you sure? According to ARIN staff, current implementation of policy is that all requests are approved since there are no defined criteria that would allow them to deny any. So far, nobody's shown interest in plugging that hole in the policy because it'd be a major step forward if IPv6 were popular enough for anyone to bother wasting it...
S
I believe Stephen is thinking of initial allocation policy - because a subsequent allocation policy in the ARIN region exists: (and it's been modified atleast once in the last few years) Justification to obtain another netblock is .94 HD-Ratio in the current allocation Endusers (minimum allocation is a /48) For a /48 that's about 72% utilization or 184 /56's assigned/used ISP's (minimum allocation is a /32) For a /32 that's about 37% utilization or 6,183,533 /56's assigned ARIN provides a handy chart: http://www.arin.net/policy/nrpm.html#six7
On Mon, Feb 2, 2009 at 9:30 PM, Anthony Roberts <nanog@arbitraryconstant.com
wrote:
It has been my experience that when you give someone a huge address space to play with (eg 10/8), they start doing things like using bits in the address as flags for things. Suddenly you find yourself using a prefix that should enough for a decent sized country in a half-rack.
Which is, of course, a core design philosophy for IPv6. Stateless autoconfig relies on the fact that each network will be allocated 2^64 address. On Mon, Feb 2, 2009 at 9:35 PM, Patrick W. Gilmore <patrick@ianai.net>wrote:
Except the RIRs won't give you another /48 when you have only used one trillion IP addresses.
Of course they will! A /48 is only the equivalent of 65536 "networks" (each network being a /64). Presuming that ISPs allocate /64 networks to each connected subscriber, then a /48 is only 65k subscribers, or say around a maximum of 200k IP addresses in use at any one time (presuming no NAT and an average of 3-4 IP-based devices per subscriber) IPv4-style utilization ratios do make some sense under IPv6, but not at the address level - only at the network level. Scott.
On Feb 4, 2009, at 6:56 PM, Scott Howard wrote:
On Mon, Feb 2, 2009 at 9:35 PM, Patrick W. Gilmore <patrick@ianai.net>wrote:
Except the RIRs won't give you another /48 when you have only used one trillion IP addresses.
Of course they will! A /48 is only the equivalent of 65536 "networks" (each network being a /64). Presuming that ISPs allocate /64 networks to each connected subscriber, then a /48 is only 65k subscribers, or say around a maximum of 200k IP addresses in use at any one time (presuming no NAT and an average of 3-4 IP-based devices per subscriber)
IPv4-style utilization ratios do make some sense under IPv6, but not at the address level - only at the network level.
First, it was (mostly) a joke. Second, where did you get 4 users per /64? Are you planning to hand each cable modem a /64? -- TTFN, patrick
Patrick W. Gilmore wrote:
On Feb 4, 2009, at 6:56 PM, Scott Howard wrote:
On Mon, Feb 2, 2009 at 9:35 PM, Patrick W. Gilmore <patrick@ianai.net>wrote:
Except the RIRs won't give you another /48 when you have only used one trillion IP addresses.
Of course they will! A /48 is only the equivalent of 65536 "networks" (each network being a /64). Presuming that ISPs allocate /64 networks to each connected subscriber, then a /48 is only 65k subscribers, or say around a maximum of 200k IP addresses in use at any one time (presuming no NAT and an average of 3-4 IP-based devices per subscriber)
IPv4-style utilization ratios do make some sense under IPv6, but not at the address level - only at the network level.
First, it was (mostly) a joke.
Second, where did you get 4 users per /64? Are you planning to hand each cable modem a /64?
That was the generally accepted subnet practice last time I had a discussion about it on the ipv6-ops list. I'm not an ISP, but I have a /48 and each subnet is a /64. Some devices will refuse to work if you subnet smaller than a /64. (Yes, poorly designed, etc.) ~Seth
On Feb 4, 2009, at 7:08 PM, Seth Mattinen wrote:
Patrick W. Gilmore wrote:
Second, where did you get 4 users per /64? Are you planning to hand each cable modem a /64?
That was the generally accepted subnet practice last time I had a discussion about it on the ipv6-ops list. I'm not an ISP, but I have a /48 and each subnet is a /64. Some devices will refuse to work if you subnet smaller than a /64. (Yes, poorly designed, etc.)
I Am Not An ISP either. :) I guess I was thinking about v4 modems which do not get a subnet, just an IP address. If we really are handing out a /64 to each DSL & Cable modem, then we may very well be recreating the same problem. And before anyone says "there are 281474976710656 /48s!", just remember your history. I was not there when v4 was spec'ed out, but I bet when someone said "four-point-two BILLION addresses", someone else said "no $@#%'ing way we will EVER use THAT many...." -- TTFN, patrick
Patrick W. Gilmore wrote:
On Feb 4, 2009, at 7:08 PM, Seth Mattinen wrote:
Patrick W. Gilmore wrote:
Second, where did you get 4 users per /64? Are you planning to hand each cable modem a /64?
That was the generally accepted subnet practice last time I had a discussion about it on the ipv6-ops list. I'm not an ISP, but I have a /48 and each subnet is a /64. Some devices will refuse to work if you subnet smaller than a /64. (Yes, poorly designed, etc.)
I Am Not An ISP either. :)
I guess I was thinking about v4 modems which do not get a subnet, just an IP address. If we really are handing out a /64 to each DSL & Cable modem, then we may very well be recreating the same problem.
And before anyone says "there are 281474976710656 /48s!", just remember your history. I was not there when v4 was spec'ed out, but I bet when someone said "four-point-two BILLION addresses", someone else said "no $@#%'ing way we will EVER use THAT many...."
Ah, but RFC 760, before 791, did assume "more than 253 networks? Nahhh..."
Patrick W. Gilmore wrote:
And before anyone says "there are 281474976710656 /48s!", just remember your history. I was not there when v4 was spec'ed out, but I bet when someone said "four-point-two BILLION addresses", someone else said "no $@#%'ing way we will EVER use THAT many...."
Let's face it - the current v6 assignment rules are to solve a 1990s set of problems. A /64 isn't needed now that we have DHCP(v6). Setting the idea in people's heads that a /64 IS going to be their own statically is insane and will blow out provider's own routing tables more than is rational. (Think of the processing overhead of all the DSL/Cable customers going up and down). This is going to be far more of an issue and drive network design than a minor blow out in the v6 routing table. As Neil Finn of Split Enz fame once wrote: History never repeats, I tell myself before I go to sleep. Followed on the same album by a song called "My Mistake". MMC (Who's trying to implement v6 native for DSL customers but finds that the world doesn't have useable solutions yet for DSL CPE, BRAS, IPv6 allocation etc and doesn't look like it will for a while). -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc@internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
In message <498A3514.1050608@internode.com.au>, Matthew Moyle-Croft writes:
Patrick W. Gilmore wrote:
And before anyone says "there are 281474976710656 /48s!", just remember your history. I was not there when v4 was spec'ed out, but I bet when someone said "four-point-two BILLION addresses", someone else said "no $@#%'ing way we will EVER use THAT many...."
Let's face it - the current v6 assignment rules are to solve a 1990s set of problems. A /64 isn't needed now that we have DHCP(v6). Setting the idea in people's heads that a /64 IS going to be their own statically is insane and will blow out provider's own routing tables more than is rational. (Think of the processing overhead of all the DSL/Cable customers going up and down). This is going to be far more of an issue and drive network design than a minor blow out in the v6 routing table.
Assign the prefixes using PD and use aggregate routes out side of the pop. IPv6 nodes are designed to be renumbered. Use the technology. Stop thinking IPv4 and start thinking IPv6. IPv6 is not just IPv4 with bigger addresses. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
Mark Andrews wrote:
Assign the prefixes using PD and use aggregate routes out side of the pop. IPv6 nodes are designed to be renumbered. Use the technology. Stop thinking IPv4 and start thinking IPv6. IPv6 is not just IPv4 with bigger addresses.
Currently with v4 I have one (majority) of customers where they have dynamic addresses. For those I'm happy to use PD - but my point was that people are starting to assume that v6 WILL mean static allocations for all customers. This is my fear, is NOT being able to use PD for the "residential grade" customers. Having to provide static allocations is a problem if I have multiple POPs in a geographic region as I can't summarise and get the redundancy I want. (If I commit to a customer they have a static range then I can't easily change it on them - esp if they've done things like used the addresses statically in DNS etc as our customers are want to do). Has anyone out there actually done an implentation, across DSL of PD? If you have PLEASE let me know on list/off list/by dead letter drop in a park. Especially interested in CPE etc. Regards, Matthew
Mark
-- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc@internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
Matthew Moyle-Croft wrote:
Currently with v4 I have one (majority) of customers where they have dynamic addresses. For those I'm happy to use PD - but my point was that people are starting to assume that v6 WILL mean static allocations for all customers. This is my fear, is NOT being able to use PD for the "residential grade" customers. Having to provide static allocations is a problem if I have multiple POPs in a geographic region as I can't summarise and get the redundancy I want.
Summary of IPv6 is easy enough, and you'll probably assign at least two /48 networks to a pop, one for infrastructure and one for PD. I'm sure there will be more.
(If I commit to a customer they have a static range then I can't easily change it on them - esp if they've done things like used the addresses statically in DNS etc as our customers are want to do).
There is a difference between static assignments to an interface for technical reasons and giving a customer a "static". Even if the customer technically has a static address, you are still allowed to change it so long as you are not giving him a static address. It's just a long term dynamic prefix. Renumbering IPv6 is a cake walk compared to IPv4, as it is somewhat more friendly to existing connections than IPv4 (if using stateless autoconfig).
Has anyone out there actually done an implentation, across DSL of PD? If you have PLEASE let me know on list/off list/by dead letter drop in a park. Especially interested in CPE etc.
Cable is much further along on CPE than most home routers. Outside of the Apple Airport, I think there's only a handful of CPE home routers with v6 capabilities. Here's someone's experience with a real home v6 implementation from ISP side to home router. http://geekmerc.livejournal.com/699.html Jack
On 5 feb 2009, at 2:20, Matthew Moyle-Croft wrote:
Has anyone out there actually done an implentation, across DSL of PD? If you have PLEASE let me know on list/off list/by dead letter drop in a park. Especially interested in CPE etc.
I've tested this years ago and it works just fine. Of course the Cisco that could do PD and the Cisco that could do v6 over ADSL were two different boxes and even one of them costs 5 - 10 x what a regular user is prepared to spend on their ADSL modem while the cheap boxes don't do v6 yet and there's tons of details to be worked out before you can buy a random cable/DSL modem and connect it to a random ISP and expect it two work. The protocols are there, we just need to agree on how to use them.
On Thu, 05 Feb 2009 11:08:44 +1030, Matthew Moyle-Croft <mmc@internode.com.au> wrote:
Let's face it - the current v6 assignment rules are to solve a 1990s set of problems. A /64 isn't needed now that we have DHCP(v6).
It's needed to prevent people from NATing in v6, as they'll still want their stuff behind a firewall, and some of them will want subnets.
Setting the idea in people's heads that a /64 IS going to be their own statically is insane and will blow out provider's own routing tables more than is rational.
No larger than their ARP tables are now.
Let's face it - the current v6 assignment rules are to solve a 1990s set of problems.
Perhaps, time moves ever forward.
A /64 isn't needed now that we have DHCP(v6). Setting the idea in people's heads that a /64 IS going to be their own statically is insane and will blow out provider's own routing tables more than is rational. (Think of the processing overhead of all the DSL/Cable customers going up and down). This is going to be far more of an issue and drive network design than a minor blow out in the v6 routing table.
However, many do not "have" DHCPv6 ... WinXP, MacOS, etc. are not capable. Also - does DHCPv6 currently have an option for prefix length? Just asking. WRT /64s (or really, /56s and /48s being assigned to clients) - note that these are NOT static assignments permanently belonging to the client. They are hopefully dynamic, hopefully via DHCPv6-PD (hopefully available/supported by then) ... similar to the single public IPv4 address most of us dynamically get @home today. AND, how does having a route for a /56 impact my routing table more than having a route for a /xx (something longer)?? It does mean the ISP needs a larger initial allocation, but still just one route ... /TJ
TJ wrote:
However, many do not "have" DHCPv6 ... WinXP, MacOS, etc. are not capable. Also - does DHCPv6 currently have an option for prefix length? Just asking.
WRT /64s (or really, /56s and /48s being assigned to clients) - note that these are NOT static assignments permanently belonging to the client. They are hopefully dynamic, hopefully via DHCPv6-PD (hopefully available/supported by then) ... similar to the single public IPv4 address most of us dynamically get @home today. Yep - that's what I'm hoping (as I've said and clarified). But I think
I'm under no allusion that a /64 is going to be optional - it's really too late which is sad. I think people have just latched onto it and now accept it and defend it without thinking about "is this still the answer?". Just because it's in an RFC doesn't mean it's still the right answer in a changing world. the reality is that in the provider world, no matter what people here say, customer demand for an unchanging IPv6 range will increase not decrease - driving up provider routing size and complexity. -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc@internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
Matthew Moyle-Croft wrote:
I'm under no allusion that a /64 is going to be optional - it's really too late which is sad. I think people have just latched onto it and now accept it and defend it without thinking about "is this still the answer?". Just because it's in an RFC doesn't mean it's still the right answer in a changing world.
My understanding is that there were long debates over if IPv6 would be 64 bits or 128 bit. 64 bits of networks should hopefully get us out of my lifetime. IPv4 wasn't always classless, though, so the rules may change, but not before we absolutely need it.
Yep - that's what I'm hoping (as I've said and clarified). But I think the reality is that in the provider world, no matter what people here say, customer demand for an unchanging IPv6 range will increase not decrease - driving up provider routing size and complexity.
We're assigning /60's via PD with network rotation, and will assign /56 or /48 if it's justified as a static assignment (though possibly handed out via PD). The latter needing SWIPs according to ARIN. A lot of people are trying to get their heads around IPv6, and the customers are really have problems with it. This isn't anything new. Tools and implementations will be built and improved to support the dynamic nature of IPv6 and make things easier for customers so that they don't have to worry about renumbers. Proper CPE routers should be able to receive PD, assign their interfaces, and even issue PD to other routers in the network. Jack
On 2009Feb4, at 8:56 PM, TJ wrote:
However, many do not "have" DHCPv6 ... WinXP, MacOS, etc. are not capable.
Maybe upgrades, service packs and updates will make them capable of using DHCPv6 for useful functions such as finding the address of an available name server by the time IPv6-only networks are in operation.
Also - does DHCPv6 currently have an option for prefix length? Just asking.
I did not see this answered in the long thread. The answer is No, prefix length comes in the Router Advertisement. John
John Schnizlein wrote:
On 2009Feb4, at 8:56 PM, TJ wrote:
However, many do not "have" DHCPv6 ... WinXP, MacOS, etc. are not capable.
Maybe upgrades, service packs and updates will make them capable of using DHCPv6 for useful functions such as finding the address of an available name server by the time IPv6-only networks are in operation.
And if not, hardcode em. It's not like your usual nameserver will be behind a nat anyway, and generally, a DNS server is a DNS server.* -Paul * Yes, there are times when your DNS server might be serving active directory DNS that's not otherwise publicly viewable, but it'll still be using globally available addressing, and you can restrict queries by IP address and range, allowing global use of the same nameserver, while only exposing the AD stuff to your internal network.
On Thu, 5 Feb 2009, Paul Timmins wrote:
John Schnizlein wrote:
Maybe upgrades, service packs and updates will make them capable of using DHCPv6 for useful functions such as finding the address of an available name server by the time IPv6-only networks are in operation.
And if not, hardcode em. It's not like your usual nameserver will be behind a nat anyway, and generally, a DNS server is a DNS server.
Er, no, open recursive resolvers are a very bad idea. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD.
On Thu, 5 Feb 2009, Matthew Moyle-Croft wrote:
DHCP(v6). Setting the idea in people's heads that a /64 IS going to be their own statically is insane and will blow out provider's own routing tables more than is rational.
Routing table size will be a function of the number of customers - *not* the prefix length assigned to them (for so long as address space is sufficiently sparsely allocated that there's a 1:1 mapping from customer to prefix - which should be "for a long time" with IPv6). So (within that longer term constraint) it doesn't matter if you're allocating your customer a /48, /56 or /64. Indeed, what you're suggesting - smaller-than-64 allocations - *would* increase routing table sizes. With your proposal those indexes would increase greatly in depth (and possibly other space increases due to not being able to optimise for "hierarchical routing of bits past 64 is highly rare"). Think of IPv6 as a 64bit network address + host address. At least for now. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: If you don't have a nasty obituary you probably didn't matter. -- Freeman Dyson
My comment was regarding customers believing that they were going to, by default, get a statically allocated range, whatever the length. If most customers get dynamically assigned (via PD or other means) then the issue is not a major one. MMC On 06/02/2009, at 8:56 PM, Paul Jakma wrote:
On Thu, 5 Feb 2009, Matthew Moyle-Croft wrote:
DHCP(v6). Setting the idea in people's heads that a /64 IS going to be their own statically is insane and will blow out provider's own routing tables more than is rational.
Routing table size will be a function of the number of customers - *not* the prefix length assigned to them (for so long as address space is sufficiently sparsely allocated that there's a 1:1 mapping from customer to prefix - which should be "for a long time" with IPv6).
So (within that longer term constraint) it doesn't matter if you're allocating your customer a /48, /56 or /64.
Indeed, what you're suggesting - smaller-than-64 allocations - *would* increase routing table sizes. With your proposal those indexes would increase greatly in depth (and possibly other space increases due to not being able to optimise for "hierarchical routing of bits past 64 is highly rare").
Think of IPv6 as a 64bit network address + host address. At least for now.
regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: If you don't have a nasty obituary you probably didn't matter. -- Freeman Dyson
-- Matthew Moyle-Croft Internode/Agile Peering and Core Networks Level 5, 162 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc@internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
Matthew Moyle-Croft wrote:
My comment was regarding customers believing that they were going to, by default, get a statically allocated range, whatever the length.
If most customers get dynamically assigned (via PD or other means) then the issue is not a major one.
Dynamic or static; how does this alter the state of the routing table? A network assigned is a network assigned. In addition, IPv6 has some decent support for mobile IP, which my limited understanding of says they enjoy routing tables the rest of us never get to see. IPv6 is designed to be renumbered. Not all implementations support this extremely well, but it is there. I believe the mobile technologies support renumber on the fly better than traditional aggregation networks who have no expectation of mobility. Jack
On 06/02/2009, at 8:56 PM, Paul Jakma wrote:
On Thu, 5 Feb 2009, Matthew Moyle-Croft wrote:
DHCP(v6). Setting the idea in people's heads that a /64 IS going to be their own statically is insane and will blow out provider's own routing tables more than is rational.
Routing table size will be a function of the number of customers - *not* the prefix length assigned to them (for so long as address space is sufficiently sparsely allocated that there's a 1:1 mapping from customer to prefix - which should be "for a long time" with IPv6).
So (within that longer term constraint) it doesn't matter if you're allocating your customer a /48, /56 or /64.
Indeed, what you're suggesting - smaller-than-64 allocations - *would* increase routing table sizes. With your proposal those indexes would increase greatly in depth (and possibly other space increases due to not being able to optimise for "hierarchical routing of bits past 64 is highly rare").
Think of IPv6 as a 64bit network address + host address. At least for now.
regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: If you don't have a nasty obituary you probably didn't matter. -- Freeman Dyson
Jack Bates wrote:
Dynamic or static; how does this alter the state of the routing table? A network assigned is a network assigned. In addition, IPv6 has some decent support for mobile IP, which my limited understanding of says they enjoy routing tables the rest of us never get to see.
Dynamic assigned addresses mean that the BRAS the customer terminates on can hand out a range out of a pool assigned to it. This means I can have a single route in my routing table for a whole BRAS (maybe 20k customers) vs 20k routes and associated processing when the dsl goes up/down/etc.
IPv6 is designed to be renumbered. Not all implementations support this extremely well, but it is there. I believe the mobile technologies support renumber on the fly better than traditional aggregation networks who have no expectation of mobility.
My car is designed to go 200km/hr or more. But the roads are implemented poorly. IPv6 is design to do everything for everyone, but the reality is the implementations aren't there or it's not practical. Mobile just creates more mess, I'm trying to make this simple and make it work. MMC -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc@internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
On Fri, Feb 6, 2009 at 7:12 PM, Matthew Moyle-Croft <mmc@internode.com.au> wrote:
Jack Bates wrote:
Dynamic or static; how does this alter the state of the routing table?... Dynamic assigned addresses mean that the BRAS the customer terminates on can hand out a range out of a pool assigned to it. This means I can have a single route in my routing table for a whole BRAS (maybe 20k customers) vs 20k routes and associated processing when the dsl goes up/down/etc.
That's not because it's doing dynamic address assignment - it's because you're only advertising the aggregate route from the BRAS/DSLAM/etc., and you can just as well do the same thing if you're using static addresses. You've got pretty much the same sized bunch of addresses and subnets regardless of how you're assigning them (except in rare cases where you're getting some statistical gain from lightly-loaded dynamic address pools), and while static addresses make it easier to use a dynamic routing protocol instead of static routing, you don't have to, or you can optionally use a dynamic routing protocol to hand routing information to the end users and then summarize at/above your BRAS. In the ipv4 world, you'd be advertising 1.2.0.0/15 either way, or a /12 if you're handing out /29s to your users instead of /32s; in the ipv6 world you'd be advertising 1337::0/39 if you're giving them /56s or 1337::0/47 if you're giving them /64s. The real difference is that if they have a static address (and can therefore advertise it with DNS easily without resorting to dynamic-DNS trickery), they may start to serve web pages, and then want to do so reliably, and then start multihoming, and then want a routing protocol to do better routing, and then either you'll need to do real work, or else you'll need to tell them to get a real circuit for their server instead of broadband, or else you'll need to tell them to use tunnels over the broadband so it's not your DSLAM/BRAS's problem. -- ---- 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.
That's not because it's doing dynamic address assignment - it's because you're only advertising the aggregate route from the BRAS/DSLAM/etc., and you can just as well do the same thing if you're using static addresses. Customers can land on one of a fleet of large BRAS across multiple POPs in a geographic region so that a failure of one piece of equipment or POP doesn't cause an outage. If I want to run a hint of redundancy
Bill Stewart wrote: then I need to propogate statics out of the POP itself. There are corners that can be cut but none seem to fit into the kind of redundancy we like. Unlike a most BGP routes DSL circuits tend to go up and down a lot, this adds to convergence time and CPU load on the router. My issue is not basic network design skills. My issue is that customers have indicated that they feel statics are a given for IPv6 and this would be a problem if I went from tens of thousands of statics to hundreds of thousands of static routes (ie. from a minority to all). Even injecting statics into iBGP rather than an IGP I feel would add considerably to the load routers face and give a big hit in the event of failure. (We already have a class of customer with statically assigned addresses or ranges). The indication so far seems to be that on this list at least people don't see IPv6 statics for all as the general option. This gives me a bit more hope. MMC -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc@internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
On Wed, Feb 4, 2009 at 4:16 PM, Patrick W. Gilmore <patrick@ianai.net>wrote:
I guess I was thinking about v4 modems which do not get a subnet, just an IP address. If we really are handing out a /64 to each DSL & Cable modem, then we may very well be recreating the same problem.
v4 just gets a single IP address, which is why we need NAT, and apparently NAT is evil. To some extent the /64 can be though of as "just an IP" from the ISP perspective (in the same sense that an IPv4 IP is just a /32 "network"), which has the ability for the CPE to then somehow split it out between multiple hosts - probably using autoconfig (in the same way with IPv4 it's "split up" by the port with NAT). What happens when a customer wants to run multiple networks is something I haven't seen answered yet - with NAT it's easy, but as I said, NAT is apparently evil... On Wed, Feb 4, 2009 at 5:20 PM, Matthew Moyle-Croft <mmc@internode.com.au>wrote:
but my point was that people are starting to assume that v6 WILL mean static allocations for all customers.
By design IPv6 should mean _less_ static allocations than IPv4 - in the event that a client disconnects/reconnects and gets a new /64 then their network *should* automatically handle that fact, with all clients automagically renumbering themselves to the new /64, updating DNS, etc. Local communications won't be impacted as they should be using the link-local address. The bit that isn't clear at the moment is if (and how well) that will actually work in practice. And that brings us back to the good old catch-22 of ISPs not supporting IPv6 because consumer CPE doesn't support it, and CPE not supporting it because ISP don't... Scott.
In message <f1dedf9c0902041735x4a9cb6f9nc5b5bbf1201a240e@mail.gmail.com>, Scott Howard writes:
On Wed, Feb 4, 2009 at 4:16 PM, Patrick W. Gilmore <patrick@ianai.net>wrote:
I guess I was thinking about v4 modems which do not get a subnet, just an IP address. If we really are handing out a /64 to each DSL & Cable modem, then we may very well be recreating the same problem.
v4 just gets a single IP address, which is why we need NAT, and apparently NAT is evil.
To some extent the /64 can be though of as "just an IP" from the ISP perspective (in the same sense that an IPv4 IP is just a /32 "network"), which has the ability for the CPE to then somehow split it out between multiple hosts - probably using autoconfig (in the same way with IPv4 it's "split up" by the port with NAT).
You hand out multiple /64's. As many as the client requests up to a /56 or /48 depending apon which break point you choose. The address space is assigned to ISP's on the presumption that you will be handing out the equivalent of /56's or /48's worth of address space to each customer.
What happens when a customer wants to run multiple networks is something I haven't seen answered yet - with NAT it's easy, but as I said, NAT is apparently evil...
On Wed, Feb 4, 2009 at 5:20 PM, Matthew Moyle-Croft <mmc@internode.com.au>wro te:
but my point was that people are starting to assume that v6 WILL mean static allocations for all customers.
By design IPv6 should mean _less_ static allocations than IPv4 - in the event that a client disconnects/reconnects and gets a new /64 then their network *should* automatically handle that fact, with all clients automagically renumbering themselves to the new /64, updating DNS, etc. Local communications won't be impacted as they should be using the link-local address.
The bit that isn't clear at the moment is if (and how well) that will actually work in practice. And that brings us back to the good old catch-22 of ISPs not supporting IPv6 because consumer CPE doesn't support it, and CPE not supporting it because ISP don't...
Scott. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
Scott Howard wrote:
On Wed, Feb 4, 2009 at 4:16 PM, Patrick W. Gilmore <patrick@ianai.net>wrote:
On Wed, Feb 4, 2009 at 5:20 PM, Matthew Moyle-Croft <mmc@internode.com.au>wrote:
but my point was that people are starting to assume that v6 WILL mean static allocations for all customers.
By design IPv6 should mean _less_ static allocations than IPv4 - in the event that a client disconnects/reconnects and gets a new /64 then their network *should* automatically handle that fact, with all clients automagically renumbering themselves to the new /64, updating DNS, etc. Local communications won't be impacted as they should be using the link-local address.
_should_ As I asked before - I'm really keen to actually do this stuff - but all I get is people who haven't done it telling me theory and not how it works in practise in a real ISP of some scale. Telling customers "well, you might get renumbered randomly" isn't going to work, no matter what the theory about it all is. They do crazy and unexpected things and bleat about it even if you told them not to. At worse they stop paying you and leave! My hope is that PD will be used for the majority and statics will be small in number. My FEAR is that customers have already been conditioned that v6 will mean statics for everyone because v6 has so many! (This has already been the assumption many have made from the customer side).
The bit that isn't clear at the moment is if (and how well) that will actually work in practice. And that brings us back to the good old catch-22 of ISPs not supporting IPv6 because consumer CPE doesn't support it, and CPE not supporting it because ISP don't...
Tell me about it. As I asked before - has ANYONE done this before? ie. fully dualstacked to customers? Or is it still theory? MMC
Scott.
-- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc@internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
Hello Matthew , See way below ... On Thu, 5 Feb 2009, Matthew Moyle-Croft wrote:
Scott Howard wrote:
On Wed, Feb 4, 2009 at 4:16 PM, Patrick W. Gilmore <patrick@ianai.net>wrote:
On Wed, Feb 4, 2009 at 5:20 PM, Matthew Moyle-Croft <mmc@internode.com.au>wrote:
but my point was that people are starting to assume that v6 WILL mean static allocations for all customers.
By design IPv6 should mean _less_ static allocations than IPv4 - in the event that a client disconnects/reconnects and gets a new /64 then their network *should* automatically handle that fact, with all clients automagically renumbering themselves to the new /64, updating DNS, etc. Local communications won't be impacted as they should be using the link-local address.
_should_
As I asked before - I'm really keen to actually do this stuff - but all I get is people who haven't done it telling me theory and not how it works in practise in a real ISP of some scale. Telling customers "well, you might get renumbered randomly" isn't going to work, no matter what the theory about it all is. They do crazy and unexpected things and bleat about it even if you told them not to. At worse they stop paying you and leave!
My hope is that PD will be used for the majority and statics will be small in number. My FEAR is that customers have already been conditioned that v6 will mean statics for everyone because v6 has so many! (This has already been the assumption many have made from the customer side).
The bit that isn't clear at the moment is if (and how well) that will actually work in practice. And that brings us back to the good old catch-22 of ISPs not supporting IPv6 because consumer CPE doesn't support it, and CPE not supporting it because ISP don't...
Tell me about it. As I asked before - has ANYONE done this before? ie. fully dualstacked to customers? Or is it still theory?
Has Anyone responded to you on/off list with even a close approximation of showing they have accomplished what you've requested ? I am beginning to be worried that no one [has|is willing to divulge] that they have accomplished this . One would think that someone would at least pipe up just for the bragging factor . Twyl , JimL -- +------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network&System Engineer | 2133 McCullam Ave | Give me Linux | | babydr@baby-dragons.com | Fairbanks, AK. 99701 | only on AXP | +------------------------------------------------------------------+
Hi James, I don't think anyone really has done it large scale properly. I've had basically nothing from anyone. Given my knowledge of where most large BRAS/Cable vendors are upto - I don't think anyone could have. (Cisco won't have high end v6 pppoe support until late this year!). There's a lot of people who clearly don't work for ISPs yammering on about the Zen of v6, but no one with real experience. Scary huh? I'm meant to have 250,000 customers running it by Christmas! MMC On 05/02/2009, at 2:44 PM, Mr. James W. Laferriere wrote:
Hello Matthew , See way below ...
On Thu, 5 Feb 2009, Matthew Moyle-Croft wrote:
Scott Howard wrote:
On Wed, Feb 4, 2009 at 4:16 PM, Patrick W. Gilmore <patrick@ianai.net
wrote:
On Wed, Feb 4, 2009 at 5:20 PM, Matthew Moyle-Croft <mmc@internode.com.au
wrote:
but my point was that people are starting to assume that v6 WILL mean static allocations for all customers. By design IPv6 should mean _less_ static allocations than IPv4 - in the event that a client disconnects/reconnects and gets a new /64 then their network *should* automatically handle that fact, with all clients automagically renumbering themselves to the new /64, updating DNS, etc. Local communications won't be impacted as they should be using the link-local address. _should_
As I asked before - I'm really keen to actually do this stuff - but all I get is people who haven't done it telling me theory and not how it works in practise in a real ISP of some scale. Telling customers "well, you might get renumbered randomly" isn't going to work, no matter what the theory about it all is. They do crazy and unexpected things and bleat about it even if you told them not to. At worse they stop paying you and leave!
The bit that isn't clear at the moment is if (and how well) that will actually work in practice. And that brings us back to the good old catch-22 of ISPs not supporting IPv6 because consumer CPE doesn't support it, and CPE not supporting it because ISP don't... Tell me about it. As I asked before - has ANYONE done this before? ie. fully dualstacked to customers? Or is it still
My hope is that PD will be used for the majority and statics will be small in number. My FEAR is that customers have already been conditioned that v6 will mean statics for everyone because v6 has so many! (This has already been the assumption many have made from the customer side). theory?
Has Anyone responded to you on/off list with even a close approximation of showing they have accomplished what you've requested ? I am beginning to be worried that no one [has|is willing to divulge] that they have accomplished this . One would think that someone would at least pipe up just for the bragging factor .
Twyl , JimL -- +------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network&System Engineer | 2133 McCullam Ave | Give me Linux | | babydr@baby-dragons.com | Fairbanks, AK. 99701 | only on AXP | +------------------------------------------------------------------+
-- Matthew Moyle-Croft Internode/Agile Peering and Core Networks Level 5, 162 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc@internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
Hmm, Apologies for that - wasn't meant to goto the list. Was a bit "frank". MMC On 05/02/2009, at 2:59 PM, Matthew Moyle-Croft wrote:
Hi James,
I don't think anyone really has done it large scale properly.
I've had basically nothing from anyone.
Given my knowledge of where most large BRAS/Cable vendors are upto - I don't think anyone could have. (Cisco won't have high end v6 pppoe support until late this year!).
There's a lot of people who clearly don't work for ISPs yammering on about the Zen of v6, but no one with real experience.
Scary huh? I'm meant to have 250,000 customers running it by Christmas!
MMC
On 05/02/2009, at 2:44 PM, Mr. James W. Laferriere wrote:
Hello Matthew , See way below ...
On Thu, 5 Feb 2009, Matthew Moyle-Croft wrote:
Scott Howard wrote:
On Wed, Feb 4, 2009 at 4:16 PM, Patrick W. Gilmore <patrick@ianai.net
wrote:
On Wed, Feb 4, 2009 at 5:20 PM, Matthew Moyle-Croft <mmc@internode.com.au
wrote:
but my point was that people are starting to assume that v6 WILL mean static allocations for all customers. By design IPv6 should mean _less_ static allocations than IPv4 - in the event that a client disconnects/reconnects and gets a new /64 then their network *should* automatically handle that fact, with all clients automagically renumbering themselves to the new /64, updating DNS, etc. Local communications won't be impacted as they should be using the link-local address. _should_
As I asked before - I'm really keen to actually do this stuff - but all I get is people who haven't done it telling me theory and not how it works in practise in a real ISP of some scale. Telling customers "well, you might get renumbered randomly" isn't going to work, no matter what the theory about it all is. They do crazy and unexpected things and bleat about it even if you told them not to. At worse they stop paying you and leave!
The bit that isn't clear at the moment is if (and how well) that will actually work in practice. And that brings us back to the good old catch-22 of ISPs not supporting IPv6 because consumer CPE doesn't support it, and CPE not supporting it because ISP don't... Tell me about it. As I asked before - has ANYONE done this before? ie. fully dualstacked to customers? Or is it still
My hope is that PD will be used for the majority and statics will be small in number. My FEAR is that customers have already been conditioned that v6 will mean statics for everyone because v6 has so many! (This has already been the assumption many have made from the customer side). theory?
Has Anyone responded to you on/off list with even a close approximation of showing they have accomplished what you've requested ? I am beginning to be worried that no one [has|is willing to divulge] that they have accomplished this . One would think that someone would at least pipe up just for the bragging factor .
Twyl , JimL -- +------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network&System Engineer | 2133 McCullam Ave | Give me Linux | | babydr@baby-dragons.com | Fairbanks, AK. 99701 | only on AXP | +------------------------------------------------------------------+
-- Matthew Moyle-Croft Internode/Agile Peering and Core Networks Level 5, 162 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc@internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
-- Matthew Moyle-Croft Internode/Agile Peering and Core Networks Level 5, 162 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc@internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
I am told that juniper have just released their E series code to do hitless failover and ipv6cp at the same time. If you are not running hitless it has been working for some time. Apologies if this message is brief, it is sent from my cellphone. On 5/02/2009, at 17:29, Matthew Moyle-Croft <mmc@internode.com.au> wrote:
Hi James,
I don't think anyone really has done it large scale properly.
I've had basically nothing from anyone.
Given my knowledge of where most large BRAS/Cable vendors are upto - I don't think anyone could have. (Cisco won't have high end v6 pppoe support until late this year!).
There's a lot of people who clearly don't work for ISPs yammering on about the Zen of v6, but no one with real experience.
Scary huh? I'm meant to have 250,000 customers running it by Christmas!
MMC
On 05/02/2009, at 2:44 PM, Mr. James W. Laferriere wrote:
Hello Matthew , See way below ...
On Thu, 5 Feb 2009, Matthew Moyle-Croft wrote:
Scott Howard wrote:
On Wed, Feb 4, 2009 at 4:16 PM, Patrick W. Gilmore <patrick@ianai.net
wrote:
On Wed, Feb 4, 2009 at 5:20 PM, Matthew Moyle-Croft <mmc@internode.com.au
wrote:
but my point was that people are starting to assume that v6 WILL mean static allocations for all customers. By design IPv6 should mean _less_ static allocations than IPv4 - in the event that a client disconnects/reconnects and gets a new /64 then their network *should* automatically handle that fact, with all clients automagically renumbering themselves to the new /64, updating DNS, etc. Local communications won't be impacted as they should be using the link-local address. _should_
As I asked before - I'm really keen to actually do this stuff - but all I get is people who haven't done it telling me theory and not how it works in practise in a real ISP of some scale. Telling customers "well, you might get renumbered randomly" isn't going to work, no matter what the theory about it all is. They do crazy and unexpected things and bleat about it even if you told them not to. At worse they stop paying you and leave!
The bit that isn't clear at the moment is if (and how well) that will actually work in practice. And that brings us back to the good old catch-22 of ISPs not supporting IPv6 because consumer CPE doesn't support it, and CPE not supporting it because ISP don't... Tell me about it. As I asked before - has ANYONE done this before? ie. fully dualstacked to customers? Or is it still
My hope is that PD will be used for the majority and statics will be small in number. My FEAR is that customers have already been conditioned that v6 will mean statics for everyone because v6 has so many! (This has already been the assumption many have made from the customer side). theory?
Has Anyone responded to you on/off list with even a close approximation of showing they have accomplished what you've requested ? I am beginning to be worried that no one [has|is willing to divulge] that they have accomplished this . One would think that someone would at least pipe up just for the bragging factor .
Twyl , JimL -- +------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network&System Engineer | 2133 McCullam Ave | Give me Linux | | babydr@baby-dragons.com | Fairbanks, AK. 99701 | only on AXP | +------------------------------------------------------------------+
-- Matthew Moyle-Croft Internode/Agile Peering and Core Networks Level 5, 162 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc@internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
!DSPAM:22,498a6b69305768916813158!
Given my knowledge of where most large BRAS/Cable vendors are upto - I don't think anyone could have. (Cisco won't have high end v6 pppoe support until late this year!).
Indeed, that is a big part of the problem in the home-user space.
There's a lot of people who clearly don't work for ISPs yammering on about the Zen of v6, but no one with real experience.
To be fair, some of those yammering work with/for enterprises/agencies/etc. that have done this; home users are not the only ones on the Internet ...
On 5 feb 2009, at 5:29, Matthew Moyle-Croft wrote:
I'm meant to have 250,000 customers running it by Christmas!
So how do you plan on doing that? We know that IPv6 runs really well over regular ethernet or over tunnels. It doesn't work so well over the weird crap that broadband ISPs use which superficially looks like ethernet or PPP but isn't (and IPv6 over PPP is very problematic). So basically your choices are giving them real ethernet, a tunnel, creating a world of hurt for yourself by pretending the broadband crap is real ethernet or getting a vendor to sell you CPEs that take care of the difference.
Iljitsch van Beijnum wrote:
So how do you plan on doing that?
It works fine to my house.
We know that IPv6 runs really well over regular ethernet or over tunnels. It doesn't work so well over the weird crap that broadband ISPs use which superficially looks like ethernet or PPP but isn't (and IPv6 over PPP is very problematic).
Not sure on PPP, but I'd suspect there's an issue still of support on the CPE side. Cisco's implementation of PPPoE/A and IPv6 seems to be easy enough. Unfortunately, I hate PPP, and the rules between v4 and v6 for RBE have changed. Latest Cisco philosophy I read is a /64 per sub-interface, stateless dhcp, and PD. The /64 assignments, while a bit messy (as if the config wasn't already messy) isn't a big deal. I haven't seen very many home routers handling PD, so I can expect that only customers without routers will actually use v6. Perhaps a few airports might do PD. Don't have one to test. While not perfect, I don't see much of an issue with the layout, although I hope Cisco adds TA to DHCPv6 soon, as there's no telling what home routers will decide to do. I have three large issues I haven't resolved yet. I have suboptimal paths for v6 compared to v4, and given the economy and the expense of upgrading core infrastructures, I do wonder if some of these companies will even survive the transition. Another issue is my own ignorance, but I still need to play with DNS in relation to IPv6, both using DDNS as well as using various support for generating templated PTR/A records on the fly. Finally, the by IP theory of SII and my CALEA gear definitely won't work well with the current IPv6 layout and privacy extension able to change the IP every so often. I'm still surprised that I haven't seen support for dynamically allocating (perhaps through radius) a /64 to a sub-interface based on it's receipt of a router solicitation. The dynamic nature of prefixes is still preferred if one values some amount of privacy on the Internet. I dislike people tracking customers by prefix. How long does it take for someone to pinpoint that a prefix won't change and start cataloging more information based on prefix that wasn't previously available via cookies? The only large caveat I've seen with Cisco is that for a 7200 VXR using RBE, 12.3T is about as far as you can go with tolerable bugs. Juniper didn't seem able to provide me with a decent plan comparable to Cisco's bridging edge. Perhaps I'm just running obsolete edge gear and haven't met the vendors everyone else liked better. Jack
On Thu, 05 Feb 2009 12:22:43 +1030, Matthew Moyle-Croft said:
Telling customers "well, you might get renumbered randomly" isn't going to work, no matter what the theory about it all is. They do crazy and unexpected things and bleat about it even if you told them not to. At worse they stop paying you and leave!
Dunno how things are Down Under, but around here, the "at worst" is *not* that they stop paying you - Joe Sixpack is a very low-margin commodity who can literally blow your year's profit with a *single* service call. "At worst" they refuse to leave and continue bleating.
On 5/02/2009, at 2:35 PM, Scott Howard wrote:
What happens when a customer wants to run multiple networks is something I haven't seen answered yet - with NAT it's easy, but as I said, NAT is apparently evil...
You give them more than a /64. RFC4291 says that it should be a /48, but people seem to be keen on / 56s now. /60s are even ok. They key here is that is is divisible by 4, which leaves full hex digits for the customer to twiddle. Somewhere (free.fr?) are doing / 61, which is a bit tough for people that aren't so technical. Here in NZ, users typically purchase their own ADSL CPE, and that runs PPPoATM over ADSL, and does IPv4 NAT and so on. What is also common, is people buy a "wireless router" and plug it in to the back of their ADSL router. They now have two layers of NAT between wireless hosts and the Internet. I looked at a packet trace of outgoing packets from an ISP - 17% of outgoing packets were from behind double NAT like this (TTL was 62 or 126, as opposed to 63 or 127). For this topology to work in IPv6, multiple levels of PD are required, or users can no longer do this sort of plug-and-pray networking. Fun fun. Personally, I think we should have PD forwarding - ie. a router can forward PD requests from routers behind it up to the ISP, and the ISP can dish out another /64. It means there are more routes in that particular router at the ISP, but it means you don't have to worry about how much address space to give to each customer - if they need more they ask for it automatically. -- Nathan Ward
On 4-Feb-2009, at 16:16, Patrick W. Gilmore wrote:
I guess I was thinking about v4 modems which do not get a subnet, just an IP address. If we really are handing out a /64 to each DSL & Cable modem, then we may very well be recreating the same problem.
All the advice I have heard about address assignment to broadband subscribers is to give each subscriber a /56, in addition to the link address (which is effectively a /128). The last time I looked, the v6 allocation of every RIR apart from ARIN recommended a /48 instead of a /56. I have been specifically advised against assigning a /64 per subscriber on the grounds that it is short-sighted, since v6 residential gateways, when they come in large numbers, will expect to be able to assign addresses to more than one subnet in the customer network.
And before anyone says "there are 281474976710656 /48s!", just remember your history.
The pertinent numbers given the thinking above are 2^24 == 16,777,216 customer /56 assignments , or 2^16 == 65536 customer /48 assignments per /32 allocation from an RIR. (If a /32 is all you have, then you will want to reserve some of that space for your own infrastructure, and the numbers above will be slightly higher than reality.) I see people predicting that giving everybody a /56 is insane and will blow out routing tables. I don't quite understand that; at the regional ISP with which I am most familiar 40,000 or so internal/ customer routes in BGP, and I have not noticed anything fall over. This is 2008: we are not dealing with routers maxed out with 256MB of RAM. And this is without any attempt to aggregate per LNS, or per POP. (This regional ISP is close to being able to provide responses to IPV6CP requests for all customers to establish an interface id, ND/RA to assign a link address, and DHCPv6 PD on request, for all customers; it's working in the lab, but hasn't yet been rolled out on the production access routers, which are all Juniper E-series devices. No, there's no direct revenue in it today; yes, the vast majority of customers are probably using XP or a residential gateway that will never talk v6.) If you need to worry about the impact on your internal routing tables of internal customer growth, then it seems you should be more worried about the impact on your routing tables of growth in the global v4 table (which is surely more rapid, and arguably can be expected to accelerate as v4 exhaustion leads to imaginative inter-organisation address assignment for fee).
I was not there when v4 was spec'ed out, but I bet when someone said "four-point-two BILLION addresses", someone else said "no $@#%'ing way we will EVER use THAT many...."
I suspect that for many regional ISPs a single allocation sufficient to number 16 million customers is probably good enough. In Canada, for example, that's half the total population, and probably larger than the total number of residences. No doubt there are a countable and significant number of super-ISPs in larger markets (or spanning multiple markets) that have requirements that out-strip that of a single /32, but I feel comfortable predicting that they are the minority in the grand scheme of things (and in any case, they can always request a larger allocation). Joe
On Wed, 4 Feb 2009, Joe Abley wrote:
I see people predicting that giving everybody a /56 is insane and will blow out routing tables. I don't quite understand that; at the regional ISP with which I am most familiar 40,000 or so internal/customer routes in BGP, and I have not noticed anything fall over. This is 2008: we are not dealing with routers maxed out with 256MB of RAM. And this is without any attempt to aggregate per LNS, or per POP.
What you do is that you do /40-44 per router or so and announce this to the rest of the network, then internally from that you assign /48 to /56 per customer out of that block. IPv6 enables us to lower address use and get less routes in the core network (both within the ISP and globally). -- Mikael Abrahamsson email: swmike@swm.pp.se
On 4-Feb-2009, at 22:59, Mikael Abrahamsson wrote:
On Wed, 4 Feb 2009, Joe Abley wrote:
I see people predicting that giving everybody a /56 is insane and will blow out routing tables. I don't quite understand that; at the regional ISP with which I am most familiar 40,000 or so internal/ customer routes in BGP, and I have not noticed anything fall over. This is 2008: we are not dealing with routers maxed out with 256MB of RAM. And this is without any attempt to aggregate per LNS, or per POP.
What you do is that you do /40-44 per router or so and announce this to the rest of the network, then internally from that you assign /48 to /56 per customer out of that block.
IPv6 enables us to lower address use and get less routes in the core network (both within the ISP and globally).
That has the down-side today that you require customers to support DHCPv6 PD in order to get their /56, though. For some providers that might be simple to organise (e.g. business- focussed ISPs whose customers use a reliably-small set of CPE). For residential customers, however, I think it's far more likely to be problematic, and hence the idea of retaining the option for static configuration seems prudent, at least at this early stage in the game. Static configuration means you need the assignment to be consistent regardless of which LNS the customer lands on. I appreciate that this approach may well be a luxury only available to relatively small ISPs, and that the approach will quite possibly need to change in the future. But it seems like a reasonable way to go for now. Joe
Joe Abley wrote:
On 4-Feb-2009, at 16:16, Patrick W. Gilmore wrote:
I guess I was thinking about v4 modems which do not get a subnet, just an IP address. If we really are handing out a /64 to each DSL & Cable modem, then we may very well be recreating the same problem.
All the advice I have heard about address assignment to broadband subscribers is to give each subscriber a /56, in addition to the link address (which is effectively a /128). The last time I looked, the v6 allocation of every RIR apart from ARIN recommended a /48 instead of a /56.
I'm not sure that that counts as "advice". Current ARIN policy takes no position as to which ISPs should do. IIRC, the /56 allowance came at the behest of a particular cable ISP that wanted to assign addresses to every home passed, whether or not the residents signed up for service, but did not want to pay for the /24 or so that would be required if they were handing out /48s -- if ARIN would even accept that flimsy justification. I can understand the technical benefits of pre-assignment, and I would have preferred that the policy (and fee schedule) were amended to better handle that case.
I have been specifically advised against assigning a /64 per subscriber on the grounds that it is short-sighted, since v6 residential gateways, when they come in large numbers, will expect to be able to assign addresses to more than one subnet in the customer network.
... which could be handled by giving out additional /64s via DHCP PD. I would expect the majority of customers to need no more than two or perhaps three subnets, with a huge fraction of that needing only one (not including the /127 to the CPE device).
I suspect that for many regional ISPs a single allocation sufficient to number 16 million customers is probably good enough. In Canada, for example, that's half the total population, and probably larger than the total number of residences.
No doubt there are a countable and significant number of super-ISPs in larger markets (or spanning multiple markets) that have requirements that out-strip that of a single /32, but I feel comfortable predicting that they are the minority in the grand scheme of things (and in any case, they can always request a larger allocation).
More importantly, we can see that in Europe, RIPE has been perfectly willing to hand out enormous allocations to such mega-ISPs. A few in the US have also gotten larger-than-/32 allocations, and IMHO that is the "correct" route, not shrinking the size of customer assignments. There are more than enough prefixes to go around in the minuscule part of the IPv6 space we're currently using. The real concerns should be (a) how we keep the number of prefixes per AS as close to 1.00 as possible, and (b) how to deal with the explosion in the number of ASes due to multihomed leaf sites. However, those problems are much harder, so some engineers are looking at how to solve problems that we already know how to solve "successfully" but don't actually matter. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
On 5 feb 2009, at 1:16, Patrick W. Gilmore wrote:
I guess I was thinking about v4 modems which do not get a subnet, just an IP address. If we really are handing out a /64 to each DSL & Cable modem, then we may very well be recreating the same problem.
IPv4 thinking. A single /64 isn't enough for a home user, because their gateway is a router and needs a different prefix at both sides. Users may also want to subnet their own network. So they need at least something like a /60.
On Thu, 05 Feb 2009 10:25:44 -0500, Iljitsch van Beijnum <iljitsch@muada.com> wrote:
On 5 feb 2009, at 1:16, Patrick W. Gilmore wrote:
I guess I was thinking about v4 modems which do not get a subnet, just an IP address. If we really are handing out a /64 to each DSL & Cable modem, then we may very well be recreating the same problem.
IPv4 thinking.
A single /64 isn't enough for a home user, because their gateway is a router and needs a different prefix at both sides. Users may also want to subnet their own network. So they need at least something like a /60.
This is not a "maybe", Mr. Gilmore. It's repeating the same mistakes of IPv4. Mr. van B, your comments would be laughable if they weren't so absurdly horrific. I've lived quite productively behind a single IPv4 address for nearly 15 years. I've run 1000 user networks that only used one IPv4 address for all of them. I have 2 private /24's using a single public IPv4 address right now -- as they have been for 6+ years. Yet, in the new order, you're telling me I need 18 billion, billion addresses to cover 2 laptops, a Wii, 3 tivos, a router, and an access point? Did we suddenly jump 20 years into the past? This is the exact same bull**** as the /8 allocations in the early days of IPv4. The idea of the "connected home" is still nowhere near *that* connected; no matter how many toys you have in your bathroom, it doesn't need a /96 of it's own. (which is an entire IPv4 of it's own.) Why do people avoid and resist IPv6... because it was designed with blind ignorance of the history of IPv4's mistakes (and how we *all* run our IPv4 networks.) Dooming us to repeating ALL those mistakes again. Exhibit A: With IPv6 Address Autoconfiguration (tm) (patent pending), you don't need DHCP. *face plant* The IPv4 mistake you've NOT learned from here is "rarp". DCHP does far more than tell a host was address it should use. (yes, I've called for the IPng WG member's execution, reanimation, and re-execution, several times.) --Ricky
On Thu, Feb 05, 2009 at 04:44:58PM -0500, Ricky Beam wrote:
[...] I've lived quite productively behind a single IPv4 address for nearly 15 years. I've run 1000 user networks that only used one IPv4 address for all of them. I have 2 private /24's using a single public IPv4 address right now -- as they have been for 6+ years. Yet, in the new order, you're telling me I need 18 billion, billion addresses to cover 2 laptops, a Wii, 3 tivos, a router, and an access point?
Thank you. Your ability to live with proxied/NATed Internet access has helped stave off the problems we're seeing now. The flip side shows up when Nintendo creates a cool new protocol for the Wii that requires Internet access. You Wii won't be able to participate until you teach your proxy/NAT box about the new protocol. I might not need a /96 for my razor, but I *do* want to have address space that allows more than one thing in my house to participate fully in use of the Internet. I have a group of gear at my house that can live in a NATted environment. Those things get RFC-1918 space, and live happily. I also have a /28 for laptops, VOIP gear, etc. -- I *like* those things to have Internet access rather than proxy-access. I have v6 space as well. I'm awaiting the day that I can get it from any common provider.
On Thu, 5 Feb 2009, John Osmon wrote:
On Thu, Feb 05, 2009 at 04:44:58PM -0500, Ricky Beam wrote:
[...] I've lived quite productively behind a single IPv4 address for nearly 15 years. I've run 1000 user networks that only used one IPv4 address for all of them. I have 2 private /24's using a single public IPv4 address right now -- as they have been for 6+ years. Yet, in the new order, you're telling me I need 18 billion, billion addresses to cover 2 laptops, a Wii, 3 tivos, a router, and an access point?
Thank you. Your ability to live with proxied/NATed Internet access has helped stave off the problems we're seeing now.
The flip side shows up when Nintendo creates a cool new protocol for the Wii that requires Internet access. You Wii won't be able to participate until you teach your proxy/NAT box about the new protocol.
What's the difference to firewalling without NAT? (Noone should connect their (home) network without at least inbound filtering) There I have to wait for the firewall box to support connection tracking for the new (broken) protocol. If the end-users really get public addresses for their WII and game-PCs, do you really think they won't just open the box totally in their firewall/router and catch/create even more problems? c'ya sven -- The lights are fading out, once more...
Wii should not even consider developing " a cool new protocol for the Wii" that is not NAT compliant via V4 or V6. And if they do, we should elect a NANOG regular to go "POSTAL" and handle the problem. The solution to many of these networking conundrums should rest with the application people, and NOT the network people. While I am ranting, my other pet peeve are proprietary protocols that the developer cannot take another couple of hours to provide a decoder for. If you develop the protocol any of the developers at the Wireshark group would help with the decode plugin. Robert D. Scott Robert@ufl.edu Senior Network Engineer 352-273-0113 Phone CNS - Network Services 352-392-2061 CNS Receptionist University of Florida 352-392-9440 FAX Florida Lambda Rail 352-294-3571 FLR NOC Gainesville, FL 32611 321-663-0421 Cell -----Original Message----- From: Sven-Haegar Koch [mailto:haegar@sdinet.de] Sent: Thursday, February 05, 2009 7:11 PM To: John Osmon Cc: NANOG list Subject: Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] On Thu, 5 Feb 2009, John Osmon wrote:
On Thu, Feb 05, 2009 at 04:44:58PM -0500, Ricky Beam wrote:
[...] I've lived quite productively behind a single IPv4 address for nearly 15 years. I've run 1000 user networks that only used one IPv4 address for all of them. I have 2 private /24's using a single public IPv4 address right now -- as they have been for 6+ years. Yet, in the new order, you're telling me I need 18 billion, billion addresses to cover 2
laptops, a Wii, 3 tivos, a router, and an access point?
Thank you. Your ability to live with proxied/NATed Internet access has helped stave off the problems we're seeing now.
The flip side shows up when Nintendo creates a cool new protocol for the Wii that requires Internet access. You Wii won't be able to participate until you teach your proxy/NAT box about the new protocol.
What's the difference to firewalling without NAT? (Noone should connect their (home) network without at least inbound filtering) There I have to wait for the firewall box to support connection tracking for the new (broken) protocol. If the end-users really get public addresses for their WII and game-PCs, do you really think they won't just open the box totally in their firewall/router and catch/create even more problems? c'ya sven -- The lights are fading out, once more...
Randy Bush wrote:
Wii should not even consider developing " a cool new protocol for the Wii" that is not NAT compliant via V4 or V6.
what is "nat compliant?"
Quite unfortunately, that has come to mean something. Specifically, TCP or UDP (and no other IP protocol numbers) and application protocols that don't depend on their locally-derived host addresses as having any meaning to anyone else. Or, in other words, "whatever the NAT maker thought was enough in order to sell boxes", which mostly means "you can look up addresses in the DNS and open http and https connections to them, and if you're lucky some of your gaming and video streaming will work too". Matthew Kaufman
Randy Bush wrote:
Wii should not even consider developing " a cool new protocol for the Wii" that is not NAT compliant via V4 or V6.
what is "nat compliant?"
RFC 3235 discusses how to make your application work in the Internet reality that exists today, with NAT boxes everywhere. The document is entitled, "Network Address Translator (NAT)-Friendly Application Design Guidelines." http://www.ietf.org/rfc/rfc3235.txt This was a product of the IETF NAT Working Group, published in 2002. Note though that this document provides guidance, not compliancy requirements. Nonetheless, application developers can find useful information on how to avoid problems. -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com Kindness in words creates confidence. Kindness in thinking creates profoundness. Kindness in giving creates love. -- Lao Tsu
On Thu, Feb 05, 2009 at 07:19:37PM -0500, Robert D. Scott wrote:
Wii should not even consider developing " a cool new protocol for the Wii" that is not NAT compliant via V4 or V6. And if they do, we should elect a NANOG regular to go "POSTAL" and handle the problem. The solution to many of these networking conundrums should rest with the application people, and NOT the network people.
You are wrong, there are lots of new ... and not so new ... protocols that *can* work via ALGs or other NAT traversal systems, but tend to work worse than if they'd had end to end visibility. The various VoIP protocols are the perfect example. The end to end principal is the lifeblood of innovation on the internet and we need to do everything we can to allow anyone who wants it to have it. Kind regards, Andy Davidson
On Mon, 9 Feb 2009, Andy Davidson wrote:
On Thu, Feb 05, 2009 at 07:19:37PM -0500, Robert D. Scott wrote:
Wii should not even consider developing " a cool new protocol for the Wii" that is not NAT compliant via V4 or V6. And if they do, we should elect a NANOG regular to go "POSTAL" and handle the problem. The solution to many of these networking conundrums should rest with the application people, and NOT the network people.
You are wrong, there are lots of new ... and not so new ... protocols that *can* work via ALGs or other NAT traversal systems, but tend to work worse than if they'd had end to end visibility. The various VoIP protocols are the perfect example.
Example please! Kind Regards, Janos Mohacsi>
In message <alpine.DEB.2.00.0902060106410.377@aurora.sdinet.de>, Sven-Haegar Ko ch writes:
If the end-users really get public addresses for their WII and game-PCs, do you really think they won't just open the box totally in their firewall/router and catch/create even more problems?
You mean they don't already list as the DMZ address. :-) WII's should be able to be directly connected to the network without any firewall. If they can't be then they are broken.
c'ya sven -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
On Fri, Feb 06, 2009 at 11:36:25AM +1100, Mark Andrews wrote: [...]
WII's should be able to be directly connected to the network without any firewall. If they can't be then they are broken.
Amen brother Mark! Can I get a hallelujah from the chorus? (Meanwhile, I'll continue to leave my Wii outside of the trusted MAC address pool in DHCP -- so it'll get an RFC-1918 address, rather the a holy "true" IP.)
Mark Andrews wrote:
WII's should be able to be directly connected to the network without any firewall. If they can't be then they are broken.
As I'm sure you know, you can tell the difference between an Internet evangelist and someone who mans the support lines by how they feel about "X should be able to be directly connected to the network without any firewall". "...then they are broken" applied to 4.3 BSD-running VAXen and Sun 3's in 1988, and neither the frequency of attacks launched nor the number of exploitable bugs in network stacks or network-packet-ingesting application programs has gone down since then. Matthew Kaufman
In message <498BDDAC.7060405@eeph.com>, Matthew Kaufman writes:
Mark Andrews wrote:
WII's should be able to be directly connected to the network without any firewall. If they can't be then they are broken.
As I'm sure you know, you can tell the difference between an Internet evangelist and someone who mans the support lines by how they feel about "X should be able to be directly connected to the network without any firewall".
"...then they are broken" applied to 4.3 BSD-running VAXen and Sun 3's in 1988, and neither the frequency of attacks launched nor the number of exploitable bugs in network stacks or network-packet-ingesting application programs has gone down since then.
Matthew Kaufman
I still believe that despite having to deal with all these issues at the time. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
This is falling outside of the IPv6/RFC-1918 discussion, so I'll only answer questions with questions... If there's need for a real discussion, I'll let someone change the subject, and continue on... On Fri, Feb 06, 2009 at 01:11:13AM +0100, Sven-Haegar Koch wrote: [...]
The flip side shows up when Nintendo creates a cool new protocol for the Wii that requires Internet access. You Wii won't be able to participate until you teach your proxy/NAT box about the new protocol.
What's the difference to firewalling without NAT? (Noone should connect their (home) network without at least inbound filtering) There I have to wait for the firewall box to support connection tracking for the new (broken) protocol.
Why do I need an "Internet breaker" (firewall) to do connection tracking? Doesn't the host computer's software stack do that when an inbound packet arrives? Why do I need a separate box to do that work with I trust my host?
If the end-users really get public addresses for their WII and game-PCs, do you really think they won't just open the box totally in their firewall/router and catch/create even more problems?
That's an issue of trusting the host... Note: All questions are hypothetical. No packets were harmed in the production of this hyperbolic response...
On 5-Feb-2009, at 13:44, Ricky Beam wrote:
This is the exact same bull**** as the /8 allocations in the early days of IPv4.
There are only 256 /8s in IPv4. There are 72,057,594,037,927,936 /56s in IPv6. If you object to where you think this is going, then perhaps it's more palatable to consider the 4,294,967,296 /32s in IPv6. [Feel free to adjust the ratios by orders of magnitude to accommodate the details that I am blandly ignoring above. It's doesn't change the message.] So in fact it's not *exactly* the same. Note that I am not denying the faint aroma of defecation in the air, nor the ghost of address assignment policies past. Also, your excitement is strangely invigorating.
[...]
Exhibit A: With IPv6 Address Autoconfiguration (tm) (patent pending), you don't need DHCP. *face plant* The IPv4 mistake you've NOT learned from here is "rarp". DCHP does far more than tell a host was address it should use. (yes, I've called for the IPng WG member's execution, reanimation, and re-execution, several times.)
You might like to review the DHCPv6 specification and try some of its implementations. There are surely simpler approaches for host configuration than the current mess, and it's surely true that the design process reached some odd conclusions on occasion, but the fact remains that the tools and protocols needed to get the job done in this regard do actually exist. It's certainly an option today to build and deploy rather than to bicker and complain. Joe
Joe Abley wrote:
Note that I am not denying the faint aroma of defecation in the air, nor the ghost of address assignment policies past.
Maybe because by sheer coincidence 2**32 /32 is exactly the same as ipv4 2**32 /32? Maybe because by sheer coincidence 2**48 /48 is exactly the same as ipv4 2**(32 network bits + 16 tcp/udp port bits = 48)? Maybe because 2**32 /32's is less than the current world population? One thing is for certain. This assignment policy is NOT enough for every particle of sand on earth, which is what I thought we were getting.
On 6/02/2009, at 12:00 PM, Joe Maimon wrote:
This assignment policy is NOT enough for every particle of sand on earth, which is what I thought we were getting.
There is enough for 3616 /64s, or 14 /56s per square centimetre of the earth's surface, modulo whatever we have set aside for multicast and non globally scoped unicast addresses and so on. If we pretend that hosts are only going to be on the area that is land, that gives us 12385 /64s, or 48 /56s per square centimetre. My suspicion is that before we get to a place where we have 48 humans per sq cm of land, we will run out of food. -- Nathan Ward
On Feb 7, 2009, at 2:09 AM, Nathan Ward wrote:
On 6/02/2009, at 12:00 PM, Joe Maimon wrote:
This assignment policy is NOT enough for every particle of sand on earth, which is what I thought we were getting.
There is enough for 3616 /64s, or 14 /56s per square centimetre of the earth's surface, modulo whatever we have set aside for multicast and non globally scoped unicast addresses and so on.
If we pretend that hosts are only going to be on the area that is land, that gives us 12385 /64s, or 48 /56s per square centimetre.
My suspicion is that before we get to a place where we have 48 humans per sq cm of land, we will run out of food.
This has nothing to do with the number of blocks per area. Nice marketing, not useful for reality. How many IP-connected devices do you have on your person right now? How many non-IP-connected devices (e.g. bluetooth) that may someday be IP-connected? And how many more will we have? If you think you can answer the last one, you are lying to yourself. We will find a way to waste & fritter away thing. We always have, we always will. In the mean time, we'll do the best with what we have. -- TTFN, patrick
On Thu, 05 Feb 2009 17:18:15 -0500, Joe Abley <jabley@hopcount.ca> wrote:
On 5-Feb-2009, at 13:44, Ricky Beam wrote:
This is the exact same bull**** as the /8 allocations in the early days of IPv4. ... So in fact it's not *exactly* the same.
Just because the address space is mind-alteringly larger does not mean the same flawed thought process isn't being used. In the mid-80's, /8's were handed out like candy because there were "lots of address space" and "we'll never use it all." Well, that didn't last very long. I've listened to IPv6 advocates singing that same song for a decade. They are doomed to repeat the same mistake. (sure, it'll take longer than with IPv4.)
You might like to review the DHCPv6 specification and try some of its implementations.
IPv6 was designed to "not need DHCP." DHCPv6 has come about since people need more than just an address from "autoconfiguration". I can recall many posts over the years from the IPng WG telling people they didn't need DHCP. --Ricky
On Thu, Feb 05, 2009 at 06:15:02PM -0500, Ricky Beam wrote:
You might like to review the DHCPv6 specification and try some of its implementations.
Joe is being a little overzealous. Unfortunately, there are very few DHCPv6 clients in the wild today. I think this has grown slightly since the last time I've had good information on it; Windows Vista, DOCSIS 3.0, Solaris and other platform specific unixes (unsure of all the right names and versions). Most free unixes have to be manhandled to install a client. The truth is it is actually not very likely that you can build an IPv6 network today using DHCPv6, unless you have large populations of those systems. Most IPv6 deployments today use SLAAC to get an address, and rely upon DHCPv4 to deliver configuration state (even IETF meetings do this). Still, it isn't bad to have a DHCPv6 server running to hand out some IPv6 addresses for configuration state now and again, so Joe is not entirely wrong.
I can recall many posts over the years from the IPng WG telling people they didn't need DHCP.
There is no need to recall! Subscribe to any IETF mailing list, and be assured you will still hear the same thing. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins
On 5-Feb-2009, at 16:14, David W. Hankins wrote:
The truth is it is actually not very likely that you can build an IPv6 network today using DHCPv6, unless you have large populations of those systems.
The particular example I've been working with is with a JUNOSe server and an IOS client which, as a solution for business DSL service, seems deployable.
[...] Joe is not entirely wrong.
Hooray! :-) Joe
On Thu, Feb 05, 2009 at 04:30:12PM -0800, Joe Abley wrote:
The particular example I've been working with is with a JUNOSe server and an IOS client which, as a solution for business DSL service, seems deployable.
Yes! Sorry, I just try to emit a little more skepticism about pervasive client support for DHCPv6 in jubliant encouragements of DHCPv6 operational experiments and deployment.
[...] Joe is not entirely wrong.
Hooray! :-)
I am seriously considering admitting I know you. :) -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins
"Ricky Beam" <jfbeam@gmail.com> writes:
... In the mid-80's, /8's were handed out like candy because there were "lots of address space" and "we'll never use it all." ...
ahem. allow me to introduce myself. i was alive and actively using the internet in the mid-80's, and when we got our /8 it was justified very differently than what you said. we had field offices in 100 countries and we had 130,000 employees and our internal network spanned five continents. (we thought long and hard about netmasks before we started rolling it out.) it was not true in Digital Equipment Corporation's (DEC's) case that a /8 was "handed out like candy" or that the justification was anything like "lots of address space" or "we'll never use it all".
IPv6 was designed to "not need DHCP." DHCPv6 has come about since people need more than just an address from "autoconfiguration".
IPv6 promised a lot of things, like no-forklift insertion of IPv6 into the existing IPv4 network, and "some hosts, such as printers, might need never be upgraded". a lot of those promises were trash, just stuff that folks had to say to get through whatever they were getting through. as much as i'd like a time machine to go back and whisper "yo, dude, that's *so* not gonna happen" in some ears, what matters to us now is not what IPv6 was promised to be or even what it could have been but instead: what it could now become.
I can recall many posts over the years from the IPng WG telling people they didn't need DHCP.
some people drink their own cool-aid. advice: get better at ignoring them. i dislike the compromises and mistakes other people will make when faced with NAT, and i don't want to live in a world dominated by products and services containing those compromises or those mistakes. i want end-to-end so i can stop budgeting half a day for each VoIP phone i send home with an employee. i don't want to remap addresses mid-path because i just know that the best programmers are the lazy ones and they WILL encode endpoint IP addrs in their sessions no matter what we tell them or how much it hurts us all. IPv6 coulda been and shoulda been lots of better things than we're getting, but due to circumstances beyond our present control, it's what we've got to work with, and it could still avoid a lot of problems whose alternative costs could be higher (NAT, double NAT, triple NAT, IPv4 markets, IPv4 black markets, IPv4 route piracy, explosive deaggregation, to name some). the most fundamental re-think required to wrap a brain around IPv6 compared to IPv4 is that we will never run out of addresses again unless someone (ignorantly) assigns a /125 to a LAN and needs more than 7 hosts thereon, or something similar. that part of IPv4's dark past will not follow us to IPv6 and we can stop thinking all related or derivative thoughts, for IPv6. but, and this matters so please pay attention, IPv6 does nothing to solve the routing table problem that IPv4 has had since 1995 or so, and IPv6 can amplify this part of IPv4's dark past and make it much worse since there can be so many more attached devices. the fundamental implication is, forget about address space, it's paperwork now, it's off the table as a negotiating item or any kind of constraint. but the size of the routing table is still a bogeyman, and IPv6 arms that bogeyman with nukes. -- Paul Vixie
the fundamental implication is, forget about address space, it's
now, it's off the table as a negotiating item or any kind of constraint. but the size of the routing table is still a bogeyman, and IPv6 arms
Paul Vixie <vixie@isc.org> wrote on 02/06/2009 02:20:01 AM: paperwork that
bogeyman with nukes.
Indeed it does. And don't forget that the most basic data object in the routing table, the address itself, is 4 times as big. Joe
Joe Loiacono wrote:
Indeed it does. And don't forget that the most basic data object in the routing table, the address itself, is 4 times as big.
Let's also not forget, that many organizations went from multiple allocations to a single allocation. If we all filter anything longer than /32, we'll rearrange the flow of traffic that many over the years have altered through longer prefixes. Even I suspect I may occasionally have to let a /40 out now and then to alter it's traffic from the rest of the aggregate. Traffic comes to you as it wants to come to you. The only pseudo remedy that currently exists is to move some prefixes over to a different path. If you only have a /32, that'll be a bit hard. This, more than anything, is what will effect this list and the people on it where IPv6 is concerned. Filtering longer than /33, 35, 40? Dare we go to /48 and treat them as the new /24? I know for myself, traffic manipulation can't begin until /40 (unless I split them further apart). Jack
On Friday 06 February 2009 08:51:04 Jack Bates wrote:
Joe Loiacono wrote:
Indeed it does. And don't forget that the most basic data object in the routing table, the address itself, is 4 times as big.
Let's also not forget, that many organizations went from multiple allocations to a single allocation. If we all filter anything longer than /32, we'll rearrange the flow of traffic that many over the years have altered through longer prefixes. Even I suspect I may occasionally have to let a /40 out now and then to alter it's traffic from the rest of the aggregate. Traffic comes to you as it wants to come to you. The only pseudo remedy that currently exists is to move some prefixes over to a different path. If you only have a /32, that'll be a bit hard.
This, more than anything, is what will effect this list and the people on it where IPv6 is concerned. Filtering longer than /33, 35, 40? Dare we go to /48 and treat them as the new /24? I know for myself, traffic manipulation can't begin until /40 (unless I split them further apart).
Jack
I think we'll see this more and more. Our newest tier-1 IPv4 transit provider was the first to tell us that they don't allow deaggregation. If we were allocated /19s, we advertise /19s... Not to start another debate, but this will certainly highlight the deficiencies of the hop-by-hop, policy-based routing paradigm that all but ignores the load-balancing needs of 95% (fictitious number) of networks operating in a world which can't load-balance itself.
On Fri, Feb 6, 2009 at 8:51 AM, Jack Bates <jbates@brightok.net> wrote:
Joe Loiacono wrote:
Indeed it does. And don't forget that the most basic data object in the routing table, the address itself, is 4 times as big.
Let's also not forget, that many organizations went from multiple allocations to a single allocation. If we all filter anything longer than /32, we'll rearrange the flow of traffic that many over the years have altered through longer prefixes. Even I suspect I may occasionally have to let a /40 out now and then to alter it's traffic from the rest of the aggregate. Traffic comes to you as it wants to come to you. The only pseudo remedy that currently exists is to move some prefixes over to a different path. If you only have a /32, that'll be a bit hard.
This, more than anything, is what will effect this list and the people on it where IPv6 is concerned. Filtering longer than /33, 35, 40? Dare we go to /48 and treat them as the new /24? I know for myself, traffic manipulation can't begin until /40 (unless I split them further apart).
Given that ARIN at least is assigning end-user /48s out of 2620::/23 it would be useful to accept these announcements. If not end-user PI is dead in the water. Some providers might like that. End-users probably won't. Tim:>
Tim Durack <tdurack@gmail.com> wrote on 02/06/2009 09:28:02 AM:
Given that ARIN at least is assigning end-user /48s out of 2620::/23 it would be useful to accept these announcements. If not end-user PI is dead in the water. Some providers might like that. End-users probably won't.
That range alone is 25 bits of routing, equivalent to routing all the way down to /25s in the IPv4 world. But I don't see how you could route some /48s without having software to route all /48s and that is hugemongous. And then times 4 for 128 bits. But, I'm not a routing engine guy, so I'm probably missing something ... Joe
On Fri, Feb 6, 2009 at 10:02 AM, Joe Loiacono <jloiacon@csc.com> wrote:
Tim Durack <tdurack@gmail.com> wrote on 02/06/2009 09:28:02 AM:
Given that ARIN at least is assigning end-user /48s out of 2620::/23 it would be useful to accept these announcements. If not end-user PI is dead in the water. Some providers might like that. End-users probably won't.
That range alone is 25 bits of routing, equivalent to routing all the way down to /25s in the IPv4 world. But I don't see how you could route some /48s without having software to route all /48s and that is hugemongous. And then times 4 for 128 bits. But, I'm not a routing engine guy, so I'm probably missing something ...
Joe
I doubt most current hardware can handle an IPv4 world full of /24s, yet they are accepted by most. Tim:>
On 6 feb 2009, at 16:02, Joe Loiacono wrote:
Given that ARIN at least is assigning end-user /48s out of 2620::/23 it would be useful to accept these announcements. If not end-user PI is dead in the water. Some providers might like that. End-users probably won't.
That range alone is 25 bits of routing, equivalent to routing all the way down to /25s in the IPv4 world. But I don't see how you could route some /48s without having software to route all /48s and that is hugemongous. And then times 4 for 128 bits. But, I'm not a routing engine guy, so I'm probably missing something ...
The problem is that ARIN reserves a /44 for every /48 they give out. So that means the most you'll see out of that /23 is 2M prefixes (I don't think there are many routers out there that can handle a v6 table this large) but since you need to accept /48s, this could be deaggregated into 32M prefixes. The RIRs need to stop this reservation stuff, it makes prefix length filtering impossible.
But I don't see how you could route some /48s without having software to route all /48s and that is hugemongous.
As currently spec'ed, you [would|should|could] allow /48s from the specific PI ranges (1/RIR?) - not just auto-accept all /48s. /TJ
Tim Durack wrote:
Given that ARIN at least is assigning end-user /48s out of 2620::/23 it would be useful to accept these announcements. If not end-user PI is dead in the water. Some providers might like that. End-users probably won't.
The ideal solution, I believe, is to support filters of max networks advertised from origin AS. This would allow for some deaggregation with some amount of protection, even if peers are not filtering their downstreams. Not sure I've seen this level of sophistication out of IOS, though. Jack
Joe Loiacono wrote:
Indeed it does. And don't forget that the most basic data object in the routing table, the address itself, is 4 times as big.
"2 times as big", if you believe that routers that need to care about table size won't do anything about what's past the /64 boundary. It still costs money. Especially since you'll also need to be carrying the v4 table for approximately forever, and it'll be deaggregating faster and faster at least for a while. Matthew Kaufman
On 5 feb 2009, at 22:44, Ricky Beam wrote:
A single /64 isn't enough for a home user, because their gateway is a router and needs a different prefix at both sides. Users may also want to subnet their own network. So they need at least something like a /60.
Mr. van B, your comments would be laughable if they weren't so absurdly horrific.
That doesn't change the fact that users would be quite constrained by only having a /64 for their internal network.
I've lived quite productively behind a single IPv4 address for nearly 15 years.
So you were already doing NAT in 1994? Then you were ahead of the curve.
I've run 1000 user networks that only used one IPv4 address for all of them.
But how is that relevant for the discussion at hand? Is your point that if 1000 users can share an IPv4 address, 1000 users should share an IPv6 address? How would that make sense? Sharing addresses comes with significant downsides. (Like having to port map services running on hosts on the inside.) Sharing one address with 1000 active users comes with even more downsides. (There are applications that need more than 64 ports so the port number space becomes a limitation.) IPv6 was specifically designed to provide an enormous amount of address space, so accepting the limitation of using one address for a large number of users means foregoing a prime feature of IPv6--for no reason that I can see.
Yet, in the new order, you're telling me I need 18 billion, billion addresses to cover 2 laptops, a Wii, 3 tivos, a router, and an access point?
The logic is like this. 1. You need more than one. 2. You don't want to change the number often (or at all) 3. What is a number that is so large that it will always be enough? Answer: the size of a MAC address. 4. How large are MAC addresses? Answer: we have technologies that have 64-bit MAC addresses. So we use 64 bits to number subnets. Now of course that seems wasteful, but those 128-bit addresses are carried in all packets anyway, and at least with 64-bit subnet sizes you get some use out of them because you know subnets are always large enough and you get to generate an address from a prefix through a function that gives you the same address without requiring anyone to remember that address, which is also useful. Now if you want to argue that IPv6 should have had 48, 53 or 64 bit addresses, that's fine. But I have to warn you that that ship sailed almost 15 years ago. (My take: they should have been variable length.)
This is the exact same bull**** as the /8 allocations in the early days of IPv4.
Oh no. A /8 is only 16777216 addresses. A /48 for an end-user organization is 1208925819614629174706176 addresses. Or, more relavant: a /8 is almost 0.5% of the IPv4 address space. A / 48 is 0.000000000003% of the currently defined global unicast IPv6 address space.
The idea of the "connected home" is still nowhere near *that* connected;
It took us 15 years to get this far with IPv6. There is no IPv7 on the horizon currently, so even if we start that tomorrow we'll have to get by with IPv6 (and IPv4...) until about 2024. I'm pretty sure we'll be *that* connected by that time.
no matter how many toys you have in your bathroom, it doesn't need a /96 of it's own. (which is an entire IPv4 of it's own.)
Like I explained, we count "0, 1, many" where the IPv6 definition of "many" happens to be 2^64. This is obviously not the single answer that is right in all cases. But the point is that there are reasons why it was a bad idea to make it less than that and no reasons that reasonably required it to be less.
Why do people avoid and resist IPv6... because it was designed with blind ignorance of the history of IPv4's mistakes (and how we *all* run our IPv4 networks.) Dooming us to repeating ALL those mistakes again.
IPv6 changes too much but it doesn't fix enough. It would be good if it didn't change much but fixed a lot, but unfortunately, that wasn't to be.
Exhibit A: With IPv6 Address Autoconfiguration (tm) (patent pending), you don't need DHCP. *face plant* The IPv4 mistake you've NOT learned from here is "rarp". DCHP does far more than tell a host was address it should use.
An IPv4 DHCP server gives me five things: an address, a prefix length, a default gateway, DNS addresses and a domain. A DHCPv6 server _can_ give me an address but I don't need it because I can generate it myself (with a little help from my friends the routers), it can't give me a prefix length or default gateway, so I still need router advertisements for those (may as well hardcode that /64 now because there is no reasonable way to get something else to work) and I don't need the domain because it's always muada.com anyway. So the only thing missing is the DNS addresses, but RFC 5006 specifies how to add this information to router advertisements. So I have no need for DHCPv6*. If someone else has, good for them and good luck with that. As long as I don't have to run a DHCPv6 server just to suck up all the broadcasts from DHCPv6 clients that are looking for DHCPv6 servers in my network. Please pick up after your dog. * except for prefix delegation to routers.
On Feb 5, 2009, at 5:42 PM, Iljitsch van Beijnum wrote:
...An IPv4 DHCP server gives me five things: ...DNS addresses and a domain...
============== Actually, lots more than five. E.g., NTP servers, preferred WINS servers (sorry, AD servers) and many other interesting (to some) items. And, the DNS domain my laptop joins depends on the network where it is connected in accordance with business policies in effect. Thus, DHCPv6 is of great interest for portable systems. I have previously noted that many clever technicians are well versed in what we do not need - without considering all the business management requirements that end user systems must meet. They are all correct, but not right. James R. Cutler james.cutler@consultant.com
James R. Cutler wrote:
Actually, lots more than five. E.g., NTP servers, preferred WINS servers (sorry, AD servers) and many other interesting (to some) items. And, the DNS domain my laptop joins depends on the network where it is connected in accordance with business policies in effect. Thus, DHCPv6 is of great interest for portable systems.
Operationally, this has been met from my experience. In fact, all of these items are handled with stateless DHCPv6 in coordination with SLAAC. Stateful DHCPv6 seems to be limited with some vendors, but unless they plan to do proxy-nd, I'm not sure they'll gain much except for end system compatibility. Jack
On Thu, Feb 05, 2009 at 05:12:19PM -0600, Jack Bates wrote:
Operationally, this has been met from my experience. In fact, all of these items are handled with stateless DHCPv6 in coordination with SLAAC. Stateful DHCPv6 seems to be limited with some vendors, but unless they plan to do proxy-nd, I'm not sure they'll gain much except for end system compatibility.
SLAAC fails in the end because you cannot predict what address the client will choose. So it fails in scenarios where enforcing network policy is important. The point of the excercise is that DHCPv4 and DHCPv6 are both supersets of network management needs. RA is a vast subset. Herein lies the rub; you have to implement both anyway because a client can not predict what network(s) it is going to be used in. Nobody wins. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins
So it fails in scenarios where enforcing network policy is important.
If the policy is address specific, perhaps. If the policy is segment specific, no prob. /TJ PS - for emphasis, I am not arguing strictly for or against either SLAAC or DHCPv6. Both can work, and IMHO should be allowed to do so where desirable.
On 6/02/2009, at 1:01 PM, David W. Hankins wrote:
On Thu, Feb 05, 2009 at 05:12:19PM -0600, Jack Bates wrote:
Operationally, this has been met from my experience. In fact, all of these items are handled with stateless DHCPv6 in coordination with SLAAC. Stateful DHCPv6 seems to be limited with some vendors, but unless they plan to do proxy-nd, I'm not sure they'll gain much except for end system compatibility.
SLAAC fails in the end because you cannot predict what address the client will choose.
So it fails in scenarios where enforcing network policy is important.
It works fine, you set the additional information flag, and the host goes to the DHCPv6 server and you can now do whatever dynamic network policy you want. This might break with privacy extensions, I'm not sure. I'm a bit confused though - do you consider it to be a good idea to set network policy differently for multiple hosts on a single broadcast domain? There are some people that do that, but as Randy would say, it is something that I would encourage my competitors to do. -- Nathan Ward
On Thu, Feb 05, 2009 at 11:42:27PM +0100, Iljitsch van Beijnum wrote:
On 5 feb 2009, at 22:44, Ricky Beam wrote:
I've lived quite productively behind a single IPv4 address for nearly 15 years.
So you were already doing NAT in 1994? Then you were ahead of the curve.
Ahh, the 90s. No need for NAT yet. http://en.wikipedia.org/wiki/SOCKS The world was smaller then. Or maybe there was just less in it?
This is the exact same bull**** as the /8 allocations in the early days of IPv4.
The man is correct: This is class-based allocations all over again. On purpose. After watching class-based allocations crash and burn. One who believes history repeats itself will think that this will only end in pain. If anything, only the timescales change. One who believes themselves to be above the mistakes of the past will of course think this plan is totally without precedent for flaw. Never between these two beliefs shall we meet. I think Ricky and Iljitsch are discovering this.
Why do people avoid and resist IPv6... because it was designed with blind ignorance of the history of IPv4's mistakes (and how we *all* run our IPv4 networks.) Dooming us to repeating ALL those mistakes again.
Exhibit A: With IPv6 Address Autoconfiguration (tm) (patent pending), you don't need DHCP. *face plant* The IPv4 mistake you've NOT learned from here is "rarp". DCHP does far more than tell a host was address it should use.
Actually it goes further back than rarp; IPv6 RA is actually more closely related to IPv4 ICMP Router Advertisements (itself a very RIP-like way to give only default routes), extended to also carry RIP-like local-prefix routes. Let's just say it's a slightly restricted (feature-limited?) RIP. So, start with that and add RARP- like features with (more complicated) client-based algorithms, and you've got the picture. But yeah, in that the static->RARP->BOOTP->DHCP progression was a dialogue between operators and IETF, IPv6 has basically thrown that dialogue out with the bathwater, and we're having it all over again. Fun! -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins
"David W. Hankins" <David_Hankins@isc.org> writes:
On Thu, Feb 05, 2009 at 11:42:27PM +0100, Iljitsch van Beijnum wrote:
On 5 feb 2009, at 22:44, Ricky Beam wrote:
I've lived quite productively behind a single IPv4 address for nearly 15 years.
So you were already doing NAT in 1994? Then you were ahead of the curve.
Ahh, the 90s. No need for NAT yet.
Does anyone remember http://en.wikipedia.org/wiki/The_Internet_Adapter ? People used to share the Internet connected *hosts*. Address sharing was implicit. Bjørn
On 6 feb 2009, at 0:55, David W. Hankins wrote:
Exhibit A: With IPv6 Address Autoconfiguration (tm) (patent pending), you don't need DHCP. *face plant* The IPv4 mistake you've NOT learned from here is "rarp". DCHP does far more than tell a host was address it should use.
Actually it goes further back than rarp; IPv6 RA is actually more closely related to IPv4 ICMP Router Advertisements
It makes more sense to look at it like this. In the 1990s we had: - IPv4: manual configuration - IPv4: DHCP - IPX: router advertised network prefix + MAC address - AppleTalk: router advertised network prefix + random number IPv6 gives us all of these.
Let's just say it's a slightly restricted (feature-limited?) RIP.
RIP is a routing protocol, not an address configuration protocol.
But yeah, in that the static->RARP->BOOTP->DHCP progression was a dialogue between operators and IETF, IPv6 has basically thrown that dialogue out with the bathwater, and we're having it all over again.
The problem is that DHCP seemed like a good idea at the time but it doesn't make any sense today. We know that parsing complex binary data formats is asking for security problems. Also, whenever you want to put something new in DHCP you must update the client and server SOFTWARE. Because on the clients, address configuration is a very fundamental thing, this is something buried deep inside the system where it's hard to make changes by anyone other than the OS vendor. What we need is a simple, fast, efficient way to distribute the basic information that a host needs to start sending and receiving packets and a pointer to a place where additional location dependent configuration information can be found. That would be: address+prefix, gateway and (arguably) DNS and then something like a URL for a server that has the config info. The system and applications can then load information from the config server over HTTP in XML format or some such.
This is straying from operational to protocol design and implementation, but as someone who has done a fair bit of both design and implementation... Iljitsch van Beijnum wrote:
The problem is that DHCP seemed like a good idea at the time but it doesn't make any sense today. We know that parsing complex binary data formats is asking for security problems...
Excuse me? This sounds like you've been hanging out with the SIP people for too long. The complexity of having a computer parse something like XML, or much worse, RFC822-style headers with complex rules about optional and mandatory options, a la SIP is *far* beyond what is required to parse things like DNS replies or even ASN.1. And *much* harder to generate strong proofs of correctness for. Just because it is easier to read without a decoder library installed in your sniffer doesn't mean it is "more secure" to parse and process. (Simple examples: binary tag/length/value formats allow immediate checking of the length to see if it is within bounds and to allocate the appropriate data structure size beforehand. With XML there's no way to know how long or deep a structure is until you've parsed the whole thing, just like with RFC822-style headers there's no way to know how long a line will be or whether or not there will be continuation lines for that tag until you've reached the next header. Which is more difficult to check for proper defense against buffer overrun attacks?) Matthew Kaufman
The problem is that DHCP seemed like a good idea at the time but it doesn't make any sense today. We know that parsing complex binary data formats is asking for security problems.
And parsing complex text data structures is better?
What we need is a simple, fast, efficient way to distribute the basic information that a host needs to start sending and receiving packets and a pointer to a place where additional location dependent configuration information can be found. That would be: address+prefix, gateway and (arguably) DNS and then something like a URL for a server that has the config info. The system and applications can then load information from the config server over HTTP in XML format or some such.
No, this information must be available in *one* place. It's called a DHCP server. As an operator, this is clearly what I want, both for IPv4 and IPv6. Steinar Haug, Nethelp consulting, sthaug@nethelp.no
sthaug@nethelp.no wrote:
No, this information must be available in *one* place. It's called a DHCP server. As an operator, this is clearly what I want, both for IPv4 and IPv6.
DHCP is available, spec'd and implemented on some systems. However, there are times that DHCP fails (from my experience). Two routers, 2 default routes. Support for shim6 or other multiple IP protocol. 2 routers, 2 global IP's assigned to the host, different default routes, and support for backup default route to opposite router. There are lots of cool things that RA's are used for, and assigning an address is just one of them. This argument over DHCP seems to be more noise; as there's room for both, and the specs and implementations exist for both. Cable modems, in particular, have a DHCP oriented nature to them; and while there are bugs being worked out on specific implementations (according to cable operators I know), they will be using DHCP with IPv6 as well. Jack
On Fri, Feb 06, 2009 at 11:50:55AM -0600, Jack Bates wrote:
Two routers, 2 default routes. Support for shim6 or other multiple IP
What most people do of course is VRRP. Barring that, you just specify multiple default routers, and the client will select the router that still responds to ARP. But support for this is not universal, so. When that isn't available, what I have done in the past here is to use the DHCP server to give out a default router option that is sorted according to the DHCP relay agent that was used to reach the server (keyed on giaddr contents). The net result is that the client uses the default gateway which it used to reach the DHCP server, and so will automatically receive an updated value if that router fails, as part of DHCP lease rebinding (it will reach the server via the alternate router). No need to take on 'routed -q' in the client, it can stay a simple dumb host, with all configuration complexity in the DHCP server or negotiated in HA by the routers. P.S. You can also set the DHCP server-identifier on the opposition of the giaddr field contents; so when the client reaches renewal time, if will be able to use the surviving router if its default router has failed (and thus will not have to wait for rebinding). This has further config implications as the server(s) are no longer able to detect the difference in a client's renewal or rebinding, but it can be an effective optimization. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins
David W. Hankins wrote:
What most people do of course is VRRP.
I agree, and I have done this in the past. However, I am very happy with the support of IPv6 to do away with requiring VRRP.
Barring that, you just specify multiple default routers, and the client will select the router that still responds to ARP. But support for this is not universal, so.
Always a problem, though arp doesn't timeout when a end node disappears in a reasonable fashion.
When that isn't available, what I have done in the past here is to use the DHCP server to give out a default router option that is sorted according to the DHCP relay agent that was used to reach the server (keyed on giaddr contents).
This is a nice method as well, though limited by the half life of the DHCP lease. It also doesn't address the fact that you might be handing out IP addresses from *both* DHCP relay agents with cross redundancy for gateways.
No need to take on 'routed -q' in the client, it can stay a simple dumb host, with all configuration complexity in the DHCP server or negotiated in HA by the routers.
Dumb hosts is exactly what makes life infuriating. I want smart hosts. The network should be relatively dumb. Perhaps I'm mistaken, but the premise of IP was that hosts are smart and networks are dumb. Then we started making smart networks to break things. I want built in multiple IP bindings on my hosts. I'd like (Windows 7 without having to call netsh, perhaps?) support for static and dynamic addresses (privacy extensions are beautiful). I especially want support for multiple dynamic addresses with communication to the host that it should start using a newer address for future requests, yet finish up what it's doing with the old address before unbonding it. Please don't get me wrong. I don't run a corporate network. I have my own little server farm and I have support to edge customers. What customer's do with the prefixes I give them is up to them. DHCP/SLAAC, it's all good. I'd rather not run DHCP for my servers or my little helpdesk network. On a standard ISP edge, I expect to see hybrid solutions; depending on the layout. Jack
On Fri, Feb 06, 2009 at 02:37:00PM -0600, Jack Bates wrote:
I agree, and I have done this in the past. However, I am very happy with the support of IPv6 to do away with requiring VRRP.
I can respect that. I don't agree with it, mostly I don't think IPv6 really has obviated that need, but it's a reasonable position to have.
This is a nice method as well, though limited by the half life of the DHCP lease. It also doesn't address the fact that you might be handing out IP addresses from *both* DHCP relay agents with cross redundancy for gateways.
Minor note; the redundancy problem isn't. :) It's solved trivially usually without any changes in config or design. DHCP just works that way.
Dumb hosts is exactly what makes life infuriating. I want smart hosts. The network should be relatively dumb. Perhaps I'm mistaken, but the premise of IP was that hosts are smart and networks are dumb. Then we started making smart networks to break things.
It is issues like this that we so often find polarizing. I'm not for a 'smart internet core', but rather for intelligent 'assist services' for simple/dumb clients to use to cross a simple/dumb network. I think expanding the behaviour of IP end hosts is going to create a real mess in terms of emergent behaviours.
I want built in multiple IP bindings on my hosts. I'd like (Windows 7
I suppose you can individually configure every host to get itself temporary addresses from RA announcements. This isn't usually a good default configuration, but OS implementation already seems to be inconsistent on the default configuration here. So we're back to the IPv4 dark ages where you have to walk around to all the devices to effect changes in policy (beyond prefix field contents). I prefer the model where I configure one (1) DHCPv6 server that does that for me. DHCPv6 and RA have all the same multiple-address features, and share the same semantics in terms of preferred and valid lifetimes. It gets back to the original philosophical question of design; should the algorithm run on the clients or on the network's assist services? Here we may never agree, but my position is that placing the burden on the assist services simplifies mandatory client implementation, and centralizes configuration management and control. Or put another way, it fulfills a larger set of requirements, while still keeping the rest as a subset of its offering. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins
On 7/02/2009, at 10:29 AM, David W. Hankins wrote:
I want built in multiple IP bindings on my hosts. I'd like (Windows 7
I suppose you can individually configure every host to get itself temporary addresses from RA announcements. This isn't usually a good default configuration, but OS implementation already seems to be inconsistent on the default configuration here. So we're back to the IPv4 dark ages where you have to walk around to all the devices to effect changes in policy (beyond prefix field contents).
I'm not sure, but you seem to be implying that you need to configure hosts to tell them to use RA or DHCPv6 to get addresses. My apologies if this is not your intention. RA messages are always going to be sent by routers and received by hosts, even if DHCPv6 is being used for address assignment. The RA message tells the host either "here is a prefix, number yourself out of it" or "go to the DHCPv6 server to get an address". OS implementation here is identical - one does not configure a host to listen for RA messages or to request addresses from DHCPv6, the host *always* listens for RA messages. Changing from SLAAC to DHCPv6 based address assignment only requires touching the router sending the RA messages. -- Nathan Ward
I suppose you can individually configure every host to get itself temporary addresses from RA announcements. This isn't usually a good default configuration, but OS implementation already seems to be inconsistent on the default configuration here. So we're back to the IPv4 dark ages where you have to walk around to all the devices to effect changes in policy (beyond prefix field contents).
I'm not sure, but you seem to be implying that you need to configure hosts to tell them to use RA or DHCPv6 to get addresses. My apologies if this is not your intention.
RA messages are always going to be sent by routers and received by hosts, even if DHCPv6 is being used for address assignment.
This does not seem to be generally true: - For the routers I am most familiar with (Juniper M/MX), you need to explicitly turn on router advertisement to make the router perform this. I.e. it is perfectly possible to have an interface with an IPv6 address which does *not* send RAs. - For the operating system I am most familiar with (FreeBSD), RAs are *not* accepted by default if the interface in question is configured with a static IPv6 address. Both of these choices seem perfectly reasonable to me. Steinar Haug, Nethelp consulting, sthaug@nethelp.no
On Sat, 7 Feb 2009, sthaug@nethelp.no wrote:
This does not seem to be generally true:
- For the routers I am most familiar with (Juniper M/MX), you need to explicitly turn on router advertisement to make the router perform this. I.e. it is perfectly possible to have an interface with an IPv6 address which does *not* send RAs.
Cisco routers do send RA by default as soon as IPv6 is enabled on the interface.
- For the operating system I am most familiar with (FreeBSD), RAs are *not* accepted by default if the interface in question is configured with a static IPv6 address.
Linux (at least Debian/Ubuntu kernels) will accept RAs by default even if you set a static IPv6 address. To stop it you have to do: sysctl net.ipv6.conf.eth0.accept_ra=0 -- Mikael Abrahamsson email: swmike@swm.pp.se
I suppose you can individually configure every host to get itself temporary addresses from RA announcements. This isn't usually a good default configuration, but OS implementation already seems to be inconsistent on the default configuration here. So we're back to the IPv4 dark ages where you have to walk around to all the devices to effect changes in policy (beyond prefix field contents).
I'm not sure, but you seem to be implying that you need to configure hosts to tell them to use RA or DHCPv6 to get addresses. My apologies if this is not your intention.
RA messages are always going to be sent by routers and received by hosts, even if DHCPv6 is being used for address assignment.
This does not seem to be generally true:
- For the routers I am most familiar with (Juniper M/MX), you need to explicitly turn on router advertisement to make the router perform this. I.e. it is perfectly possible to have an interface with an IPv6 address which does *not* send RAs.
Yes, vendors differ ... for Ciso/IOS - broadcast capable, multi-access interfaces (a la Ethernet) will automatically send RAs ones a /64 IPv6 address is configured. Or once you explicitly tell it to advertise one.
- For the operating system I am most familiar with (FreeBSD), RAs are *not* accepted by default if the interface in question is configured with a static IPv6 address.
I don't believe that is the general behavior, and specifically - for Win* a static being configured does not prevent autoconfiguration. And this is the correct behavior - to allow for cases where multiple prefixes are correct/expected, and only one is static.
Both of these choices seem perfectly reasonable to me.
I slightly disagree on the latter; autoconfiguration in the presence of RAs (including a (or several) prefix options) should be the default. ((... and now begins (continues, really) the pseudo-religious debate between the autoconfiguration people and the DHCPv6 people ...)) /TJ
On Sat, Feb 07, 2009 at 07:51:36PM +1300, Nathan Ward wrote:
I'm not sure, but you seem to be implying that you need to configure hosts to tell them to use RA or DHCPv6 to get addresses. My apologies if this is not your intention.
Close, but it is worth clearing up.
RA messages are always going to be sent by routers and received by hosts, even if DHCPv6 is being used for address assignment.
Most clients "default out of the box" to accept RA, getting a single address within each prefix indicating automatic address assignment. The ones that do support DHCPv6 will also initiate DHCPv6 services based on RA M and O flags. There are some bugs here and there, but it mostly works. This is all well and good, you are right on these points. However, Jack was referring to a practice of "temporary address" assignments. In this configuration, a client has one "permanent" (for as long as they are on that wire) address they use (per prefix, because that is how IPv6 multihomes, so they say) for general purpose and reachability from the outside world ("dial in"). They also have a range of "temporary" addresses which are in a state of preferred use, unpreferred use, or validity-timer expiration (again, per prefix, for multi-homing). Each temporary address is allocated based on a re-hash of a previously used seed, and half of the seed bits are not used in the public address (so outsiders can not easily predict what the client's next address will be). The theory is that these temporary addresses enhance privacy, as the client seems to hop from address to address. This seems to ignore application context hints such as cookies and keys embedded in URL's, so to my thinking the point of this is to enhance privacy for spammers or illegal file sharers. Anyway. So far as I am aware, this is default behaviour only on certain versions of Mac OSX, and must be explicitly enabled on all others. Manually, on the console. RA does not dynamically distribute this behaviour; the client has to choose it. Usually it is a sysctl or a registry variable or the like. Conversely, with DHCPv6, clients that support "normal" and "temporary" addresses simply always ask for them; this indicates they possess support. The service determines which type of address to actually provide (one, the other, both, with multiple bindings in either). In this way, all is automated from a central point. The philosophies of design of these two systems are entirely at odds. In RA the client determines what configuration it seeks, placing its own arbitrary demands upon the network, but still heeds some of its vague handwaving. In DHCPv6, the client submits to the network's will, but still has some of its own vague handwaving choices. It is Marxism (turned Socialism) vs Fascism at its root. I hope I have not spent my year's worth of NANOG tolerance for DHCP related discussions with the above. :) -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins
So far as I am aware, this is default behaviour only on certain versions of Mac OSX, and must be explicitly enabled on all others. Manually, on the console. RA does not dynamically distribute this behaviour; the client has to choose it. Usually it is a sysctl or a registry variable or the like.
NIT: Add any IPv6 capable Windows "workstation" to that list (workstation meaning "not server" OS). Or any USAGI-derived 'nix kernel, AFAIK. (WinXP as described/expected, Vista with a twist (no EUI64 by default))
The philosophies of design of these two systems are entirely at odds.
While I agree with that statement, I disagree just a little bit with your supporting argument. On either case, the host is initiating the discussion and trying to do what it wants (either appending randomized IIDs or asking the DHCPv6 server to supply it with randomly generated IIDs, and using the results as "(a) temporary/privacy address(es)") ... in either case, if the hosts doesn't support it or doesn't ask, it doesn't happen. /TJ
On Feb 6, 2009, at 12:37 PM, Jack Bates wrote:
David W. Hankins wrote:
What most people do of course is VRRP.
I agree, and I have done this in the past. However, I am very happy with the support of IPv6 to do away with requiring VRRP.
If RA does that in your situation, great. In my situation, there are actually cases where I need different VRRP groups on the same LAN and need to point different things at different routers from hosts. It would be nice if DHCPv6 (or DHCPv4 for that matter) could include not only a default, but, a static routing table in what it distributes. Nonetheless, the built in assumption in IPv6 RA that all routers are equal is simply not valid in all environments and VRRP with DHCP provides some ability to cope in environments where that isn't true.
Barring that, you just specify multiple default routers, and the client will select the router that still responds to ARP. But support for this is not universal, so.
Always a problem, though arp doesn't timeout when a end node disappears in a reasonable fashion.
Some OS handle this better than others. Try, wait, try, wait, re-arp, wait, fall over to other gateway -- 9 sec. delay in some situations.
When that isn't available, what I have done in the past here is to use the DHCP server to give out a default router option that is sorted according to the DHCP relay agent that was used to reach the server (keyed on giaddr contents).
This is a nice method as well, though limited by the half life of the DHCP lease. It also doesn't address the fact that you might be handing out IP addresses from *both* DHCP relay agents with cross redundancy for gateways.
I'm not sure what you mean by that.
No need to take on 'routed -q' in the client, it can stay a simple dumb host, with all configuration complexity in the DHCP server or negotiated in HA by the routers.
Dumb hosts is exactly what makes life infuriating. I want smart hosts. The network should be relatively dumb. Perhaps I'm mistaken, but the premise of IP was that hosts are smart and networks are dumb. Then we started making smart networks to break things.
That's great on paper, but, in some real world scenarios, it's not as supportable as one might want. The best thing is if both are smart in helpful ways and are willing to be told not to out-smart themselves in environments where that is counterproductive.
I want built in multiple IP bindings on my hosts. I'd like (Windows 7 without having to call netsh, perhaps?) support for static and dynamic addresses (privacy extensions are beautiful). I especially want support for multiple dynamic addresses with communication to the host that it should start using a newer address for future requests, yet finish up what it's doing with the old address before unbonding it.
Could you please explain a good reliable method for source address selection in a multiple IP binding scenario? That last one is available albeit really hard to support in any sort of scale.
Please don't get me wrong. I don't run a corporate network. I have my own little server farm and I have support to edge customers. What customer's do with the prefixes I give them is up to them. DHCP/ SLAAC, it's all good. I'd rather not run DHCP for my servers or my little helpdesk network. On a standard ISP edge, I expect to see hybrid solutions; depending on the layout.
I don't know very many people who want DHCP for servers. However, when you're managing a bunch of user's desktops and laptops, DHCP is the only way to scale things reasonably in some environments. Owen
It would be nice if DHCPv6 (or DHCPv4 for that matter) could include not only a default, but, a static routing table in what it distributes.
In theory, RAs can - "more specific routes", although I don't believe any vendor (router or client side) supports these as of yet ... (Default Router Preference more widely supported, but less granular)
Could you please explain a good reliable method for source address selection in a multiple IP binding scenario?
RFC3484 being revisited as we speak, feel free to help :) ... may include things like policy table updates to clients ... Note - no great/clean answer yet to the "multi-homed to disparate networks" scenario. (It's a hard problem to automagically solve for all cases) /TJ
What most people do of course is VRRP.
Sure, or HSRP or GLBP ... all still doable.
Barring that, you just specify multiple default routers, and the client
will
select the router that still responds to ARP. But support for this is not universal, so.
Indeed, not universal and in fact default behaviors vary wildly.
When that isn't available, what I have done in the past here is to use the DHCP server to give out a default router option that is sorted according to the DHCP relay agent that was used to reach the server (keyed on giaddr contents).
The net result is that the client uses the default gateway which it used to reach the DHCP server, and so will automatically receive an updated value
if
that router fails, as part of DHCP lease rebinding (it will reach the server via the alternate router).
Which I think is pretty slick. OOC - between the "router fails" and "I renew/rebind my address", is the host down and out? So you are accepting either a noticeable outage or tweaking your lease times, yes?
DHCP items are end system considerations, not routing network considerations. The network operations staff and router configuration engineers do not generally concern themselves with end systems. End systems generally are managed quite independently from the routing network. And, they are more subject to the vagaries of day to day business variability. Note the "one place" in the quoted message below. The only overlap is broadcast forwarding for DHCP initiation. Besides, configuration control is hard enough for router engineers without adding the burden of changing end system requirements. Adding the forwarding entries is almost too much already! ;) So, for routing network operators to denigrate DHCP is probably due to lack of consideration of the end user system requirements. And those who denigrate DHCP and say "just hard code it" make end system management that much more difficult. I still conclude that DHCP is a useful tool for both IPv4 and IPv6 systems. Cutler On Feb 6, 2009, at 12:22 PM, sthaug@nethelp.no wrote:
The problem is that DHCP seemed like a good idea at the time but it doesn't make any sense today. We know that parsing complex binary data formats is asking for security problems.
And parsing complex text data structures is better?
What we need is a simple, fast, efficient way to distribute the basic information that a host needs to start sending and receiving packets and a pointer to a place where additional location dependent configuration information can be found. That would be: address +prefix, gateway and (arguably) DNS and then something like a URL for a server that has the config info. The system and applications can then load information from the config server over HTTP in XML format or some such.
No, this information must be available in *one* place. It's called a DHCP server. As an operator, this is clearly what I want, both for IPv4 and IPv6.
Steinar Haug, Nethelp consulting, sthaug@nethelp.no
James R. Cutler james.cutler@consultant.com
I think this part of the thread is in danger of leaving the realm of operational relevance, so I will treat these as my closing arguments. On Fri, Feb 06, 2009 at 03:48:53PM +0100, Iljitsch van Beijnum wrote:
It makes more sense to look at it like this. In the 1990s we had:
No, I think that "shopping checklist view" is exactly the kind of wrong thinking that stunts the dialogue between tools and needs, and has been a cause in IPv6's current disconnect in operational reality. So no, I don't think it makes any sense to look at it like that. It makes the most sense to look at the IPv4 configuration protocols alone as a progression of tools, each built upon what was learned from the prior, and the conclusions that were determined to work best for most of the Internet's operators (neither Appletalk's nor IPX's). These conclusions were proper supersets of previously determined operational needs, and so became a pervasively deployed universal solution. This is a functioning model for tool growth. Shopping checklists only create Frankenstein monsters, stunted half-breeds that serve only their creators.
RIP is a routing protocol, not an address configuration protocol.
This is a statement whose context predicates that you think I don't know that, which further confers that my intended message has been lost on you. This is far afield from the point! I am predisposed not to correct this, as the message was not intended for you, I hope this is mutually agreeable. :)
asking for security problems. Also, whenever you want to put something new in DHCP you must update the client and server SOFTWARE. Because on the
This actually is not true, which I have told you before. But I have to admit it is a nice contrived false factoid that supports your a-priori conclusions. My analysis of your further arguments is that you have selected a proper subset of actual Internet operational needs in order to further justify these same conclusions. I will leave it at that. :) -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins
On Thu, 05 Feb 2009 17:42:27 -0500, Iljitsch van Beijnum <iljitsch@muada.com> wrote:
I've lived quite productively behind a single IPv4 address for nearly 15 years.
So you were already doing NAT in 1994? Then you were ahead of the curve.
"NAT" didn't exist in '94. But, Yes. And, Yes. I had several computers networked behind one with a dialup (PPP) connection. And, as you'd expect, it was messy.
I've run 1000 user networks that only used one IPv4 address for all of them.
But how is that relevant for the discussion at hand? Is your point that if 1000 users can share an IPv4 address, 1000 users should share an IPv6 address?
The point is... even large enterprises don't *need* 18 billion, billion addresses to get anything done. I see IPv6 address space being carved out in huge chunks for reasons that equate to little more than because the total space is "inexhaustable". This is the exact same type of mis-management that plagues us from IPv4's early allocations.
Now of course that seems wasteful, ... and you get to generate an address from a prefix through a function that gives you the same address without requiring anyone to remember that address, which is also useful.
Well, it is extremely wasteful. If you want the machine to always have the same address, either enter it manually or set your DHCP server to always give it the same address. We do that already with IPv4. Why do we need to waste so much space with such a sparse address plan? We don't. But since IPv6 is H.U.G.E., "might as well." And face reality, many people have enough trouble remembering IPv4 addresses -- even when it's simplified to a /24 prefix plus 3 digit number. They will have an even harder time remembering a 48bit or 64bit MAC. Do you remember the MAC addresses of ANY of the NICs on your lan(s)?
This is the exact same bull**** as the /8 allocations in the early days of IPv4.
Oh no. ...
Yes. It. Is. We have this incomprehensibly huge address space that we cannot possibly, EVER, use up, so let's divide it on ridiculously huge boundries.
The idea of the "connected home" is still nowhere near *that* connected;
It took us 15 years to get this far with IPv6. There is no IPv7 on the horizon currently, so even if we start that tomorrow we'll have to get by with IPv6 (and IPv4...) until about 2024. I'm pretty sure we'll be *that* connected by that time.
I'm not. I'll be very surprised if IPv6 has been universally adopted by then. I'm not sure we'll be completely out of IPv4 space by then.
IPv6 changes too much but it doesn't fix enough.
It's not even that. Had they simply not ignored, and out-right dismissed as "wrong", the way networks were being run, then we wouldn't have the mess we have today. I pick on autoconfig because it's the simplest bit of stupid on their part... we have Stateless Autoconfiguration, *jedi hand wave*, you don't need DHCP. It was bull the instant they said it. You don't use DHCP. Well, good for you. There are hunreds of thousands of people who do. We appreciate you telling us we don't need the technology we need. (It's the "I don't use it so nobody else needs to, either" attitude that has given us a whole bunch of things to re-invent for IPv6.) --Ricky
On 6 feb 2009, at 1:15, Ricky Beam wrote:
I see IPv6 address space being carved out in huge chunks for reasons that equate to little more than because the total space is "inexhaustable". This is the exact same type of mis-management that plagues us from IPv4's early allocations.
Think of it this way: if addresses are going to be wasted, I'll be happy to take my share an un-waste as required. For instance, there have been suggestions to move the /64 subnet boundary to /80 because 64-bit MAC addresses never took off. I'll take my /64s now and then move the boundary to /80 later so I can multiply the number of subnets that I have by 65536. This is a whole lot more pleasant that slicing and dicing that single IPv4 address in ever tinier parts as I get more stuff that runs IP in my house. (And there is a real risk that I won't even have that single IPv4 address anymore in the future but have to share one with my neighbors.) IPv6 is a whole new way of doing things. It doesn't make sense to apply IPv4 sensitivities here, just like in the middle of the ocean, water management is a different game than in the desert. You could make a fair case that 48 bits would have been sufficient for IPv6 (6/4th of 32 bits after all) and then we'd have to manage that space pretty much the same as today's IPv4 space. But it's almost three times that.
you get to generate an address from a prefix through a function that gives you the same address without requiring anyone to remember that address, which is also useful.
Well, it is extremely wasteful.
Not really. The waste started and ended with the decison to make IPv6 addresses 128 bits. Now that you have to carry those 128 bits in all your packets, there is no additional penalty for actually using them.
If you want the machine to always have the same address, either enter it manually or set your DHCP server to always give it the same address.
Manual configuration doesn't scale. With IPv4, it's quite hard to make this work with DHCP, but mostly because of a lack of IPv4 addresses. With IPv6 it's easier, but you're still limiting the uptime of your system to that of the DHCPv6 server. Router advertisements is much more robust.
And face reality, many people have enough trouble remembering IPv4 addresses -- even when it's simplified to a /24 prefix plus 3 digit number. They will have an even harder time remembering a 48bit or 64bit MAC. Do you remember the MAC addresses of ANY of the NICs on your lan(s)?
Isn't remembering stuff what we have computers for?
It's not even that. Had they simply not ignored, and out-right dismissed as "wrong", the way networks were being run, then we wouldn't have the mess we have today. I pick on autoconfig because it's the simplest bit of stupid on their part... we have Stateless Autoconfiguration, *jedi hand wave*, you don't need DHCP. It was bull the instant they said it.
I have a lot of problems with DHCP and most people don't _need_ it. Still, very many people _want_ it and some people do in fact need it. I have no problem with that, as long as it doesn't lead to the situation where I have to run it.
On Fri, 06 Feb 2009 09:39:01 -0500, Iljitsch van Beijnum <iljitsch@muada.com> wrote:
If you want the machine to always have the same address, either enter it manually or set your DHCP server to always give it the same address.
Manual configuration doesn't scale. With IPv4, it's quite hard to make this work with DHCP, but mostly because of a lack of IPv4 addresses. With IPv6 it's easier, but you're still limiting the uptime of your system to that of the DHCPv6 server. Router advertisements is much more robust.
As I read it, you don't want to use DHCP because "it's an other service to fail." Well, what do you think is broadcasting RA's? My DHCP servers have proven far more stable than my routers. (and one of them is a windows server :-)) Most dhcp clients that keep any state will continue using the previously assigned address if the server is unavailable (and nothing else is using it.) Configuring a static address in a DHCP server is a pretty trivial task. My point is simply, this whole mess with RA's should never have been on the table. DHCP has been around and used for years to provide IPv4 hosts with an address, gateway, and MANY other configuration options. It exists because (in many cases) hosts need more than just an address. Yet the protocol designers, staunch haters of DHCP, refused to see any value in DHCP for IPv6 and rolled back the clock 3 decades dooming us ALL to repeating the same bull. DHCPv6 can do everything SLAAC can plus infintely more. And an "it just works" configurationless setup could have been part of the standard instead; yet here we are... nobody 100% happy and a considerable amount of work being poured into reinventing the DHCP wheel. Manual static configuration is indeed a pain. That's why we have DHCP... set aside a range of addresses for machines that can move around (client workstations, etc.) and a pool of persistant addresses for servers, printers, etc. that you want to stay in one place -- some applications record addresses instead of names, *sigh*. Everything is in one, easy to manage location. For an ISP where a lot necessarily has to be manually configured, it can be more work, but is still simple -- even in the days of the "NOC NOTEBOOK" where only one person could be assigning addresses at a time. (we've had web based stuff for years now; feed rwhois directly, 'tho not automatic.)
Isn't remembering stuff what we have computers for?
If you aren't accessing machines by number, why do you care if it always has the same number? As long as the name always maps to the right number, it doesn't matter.
I have a lot of problems with DHCP and most people don't _need_ it. Still, very many people _want_ it and some people do in fact need it. I have no problem with that, as long as it doesn't lead to the situation where I have to run it.
And I, likewise, don't want the utterly useless "RA" forced on my networks. Hosts need much more than just a unique address. And I don't want to have to walk around to every one of them to change anything. --Ricky
As I read it, you don't want to use DHCP because "it's an other service to fail." Well, what do you think is broadcasting RA's? My DHCP servers have proven far more stable than my routers. (and one of them is a windows server :-)) Most dhcp clients that keep any state will continue using the previously assigned address if the server is unavailable (and nothing else is using it.) Configuring a static address in a DHCP server is a pretty trivial task.
My point is simply, this whole mess with RA's should never have been on the table. DHCP has been around and used for years to provide IPv4 hosts with an address, gateway, and MANY other configuration options. It exists because (in many cases) hosts need more than just an address. Yet the protocol designers, staunch haters of DHCP, refused to see any value in DHCP for IPv6 and rolled back the clock 3 decades dooming us ALL to repeating
Your routers fail frequently? And does your traffic continue to get forwarded? Perhaps through another router? ... which would work the same way in an IPv6 scenario ... with the host knowing it's address for a period of time (Valid timer), and learning a new gateway in fairly short order (even sans FHRP). the
same bull. DHCPv6 can do everything SLAAC can plus infintely more. And an "it just works" configurationless setup could have been part of the standard instead; yet here we are... nobody 100% happy and a considerable amount of work being poured into reinventing the DHCP wheel.
Why is there a problem with RAs being the first step, possibly including prefix info or possibly just hinting @ DHCPv6?
Manual static configuration is indeed a pain. That's why we have DHCP... set aside a range of addresses for machines that can move around (client workstations, etc.) and a pool of persistant addresses for servers, printers, etc. that you want to stay in one place -- some applications record addresses instead of names, *sigh*. Everything is in one, easy to manage location. For an ISP where a lot necessarily has to be manually configured, it can be more work, but is still simple -- even in the days of the "NOC NOTEBOOK" where only one person could be assigning addresses at a time. (we've had web based stuff for years now; feed rwhois directly, 'tho not automatic.)
Isn't remembering stuff what we have computers for?
If you aren't accessing machines by number, why do you care if it always has the same number? As long as the name always maps to the right number, it doesn't matter.
I have a lot of problems with DHCP and most people don't _need_ it. Still, very many people _want_ it and some people do in fact need it. I have no problem with that, as long as it doesn't lead to the situation where I have to run it.
And I, likewise, don't want the utterly useless "RA" forced on my networks. Hosts need much more than just a unique address. And I don't want to have to walk around to every one of them to change anything.
Well, as it stands now the RA isn't useless. It, and it alone, provides default gateway information ... from the default gateway itself. (I actually think that this is architecturally superior, but that is just my opinion ... ) ((The rest of the info, (addressing or other) can be obtained via RA/SLAAC or DHCPv6)) Also, it is not true in every case that hosts need a "lot more" than an address. In many cases all my machine needs is an address, default gateway and DNS server (cheat off of v4 | RFC5006 | Stateless DHCPv6).
In message <00cf01c98b24$efe42680$cfac7380$@com>, "TJ" writes:
Also, it is not true in every case that hosts need a "lot more" than an address. In many cases all my machine needs is an address, default gateway and DNS server (cheat off of v4 | RFC5006 | Stateless DHCPv6).
address + default gateway. I know where the root servers live :-) -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
On Mon, 09 Feb 2009 21:11:50 -0500, TJ <trejrco@gmail.com> wrote:
Your routers fail frequently? And does your traffic continue to get forwarded? Perhaps through another router?
More frequently than the DHCP server, but neither are "frequent" events. Cisco's software is not 100% perfect, and when you plug it into moderately unstable things like phone lines (DSL) and cable networks, those little bugs cause reloads -- you'd think they'd have better error handling, but they don't. (I don't buy millions in equipment from Cisco so they don't care about my problems.) While I could use backup links, flip-floping between ISPs with different addresses is not ideal (and that's as true for v6 as v4.)
Why is there a problem with RAs being the first step, possibly including prefix info or possibly just hinting @ DHCPv6?
Because it doesn't fit the needs of *every* network. In fact, it's only "good enough" for very few networks. As such it just adds more useless layers of bloat.
Well, as it stands now the RA isn't useless. ... Also, it is not true in every case that hosts need a "lot more" than an address. In many cases all my machine needs is an address, default gateway and DNS server (cheat off of v4 | RFC5006 | Stateless DHCPv6).
It's useless. It does NOT provide enough information alone for a host to function. In your own words, you need a DNS server. That is NOT provided by RA thus requires yet another system to get that bit of configuration to the host -- either entered manually, DHCPv6, or from IPv4 network configuration (ie. DHCP!) Forcing this BS on the world is a colossal waste. We've had a system to provide *ALL* the information a host needs or wants in the IPv4 world for years. Why it's not good enough for IPv6 is beyond me. --Ricky
Your routers fail frequently? And does your traffic continue to get forwarded? Perhaps through another router?
More frequently than the DHCP server, but neither are "frequent" events. Cisco's software is not 100% perfect, and when you plug it into moderately unstable things like phone lines (DSL) and cable networks, those little bugs cause reloads -- you'd think they'd have better error handling, but they don't. (I don't buy millions in equipment from Cisco so they don't care about my problems.) While I could use backup links, flip-floping between ISPs with different addresses is not ideal (and that's as true for v6 as v4.)
But my real point was if the router is failed, traffic isn't being forwarded regardless of how the host got the information ... correct? And vendor support issues are a layer 8-11 problem ... no layer 3 fix for that! (8-11 == people politics religion money ... in no particular order)
Why is there a problem with RAs being the first step, possibly including prefix info or possibly just hinting @ DHCPv6?
Because it doesn't fit the needs of *every* network. In fact, it's only "good enough" for very few networks. As such it just adds more useless layers of bloat.
Obviously we disagree, fundamentally.
Well, as it stands now the RA isn't useless. ... Also, it is not true in every case that hosts need a "lot more" than an address. In many cases all my machine needs is an address, default gateway and DNS server (cheat off of v4 | RFC5006 | Stateless DHCPv6).
It's useless. It does NOT provide enough information alone for a host to function. In your own words, you need a DNS server. That is NOT provided by RA thus requires yet another system to get that bit of configuration to the host -- either entered manually, DHCPv6, or from IPv4 network configuration (ie. DHCP!) Forcing this BS on the world is a colossal waste. We've had a system to provide *ALL* the information a host needs or wants in the IPv4 world for years. Why it's not good enough for IPv6 is beyond me.
Technically, that is a gap RFC5006 would fill - once supported, which should have been long before now but too late for that, eh? And I think we also disagree on a fundamental aspect, specifically - I see it this way: 1) the RAs are there primarily to allow a router to provide information about itself to the hosts on the link a) which becomes the default gateway from the hosts' perspective 2) Everything after that is a separate thing, namely - host addressing and "other" configuration a) which could be SLAAC, by including a prefix in the RA ... and maybe a DNS server option, someday. -) and maybe Stateless DHCPv6 as well, for the DNS or other missing info b) which could be DHCPv6, providing all of the addressing and config info (but not router info) I think the key factor to our disagreement is that I think it makes great sense for the router to provide information about itself to the hosts, and you'd rather it be centralized. I don't really care either way, to be honest - it just seems to make good sense (to me) the way it works now. If I understand correctly the answer, from your standpoint, would be to author an RFC specifying a default gateway option for DHCPv6 (and maybe a prefix length option as well?). And then get DHCPv6 client functionality itself, and this option, more widely supported (and in fact, "on by default"). As to "why it's not good enough" ... well, suffice it to say this debate has raged for a LOOOONG time and apparently sufficient consensus (for reasons good or ill) was reached at some point for the way it is now. Build consensus to change that (factoring in the pain it would cause to current deployments) ... maybe starting off small, with just defining the option and convincing a major vendor or two to implement it ... if the world agrees, it will migrate to working that way ... isn't that how this whole open standards process is supposed to work? (OK, that last question was a bit rhetorical and was not meant to spark a debate about this being the IETF vs the IVTF vs the ______ etc. etc. Sorry!) Failing that (or while that is ongoing?) ... we have what we have. And it does indeed work, today, for almost all * cases. So let's get deploying, go team! * - as discussed at length on this list and others /TJ "Be conservative in what you send and liberal in what you accept." --Jon Postel "The future belongs to those who see possibilities before they become obvious." --unknown "In essentials, unity; in non-essentials, liberty; in all things, charity" --various "Everyone's a hero in their own way, in their own not that heroic way." --Joss Whedon
On 11/02/2009, at 10:41 AM, Ricky Beam wrote:
It's useless. It does NOT provide enough information alone for a host to function. In your own words, you need a DNS server. That is NOT provided by RA thus requires yet another system to get that bit of configuration to the host -- either entered manually, DHCPv6, or from IPv4 network configuration (ie. DHCP!) Forcing this BS on the world is a colossal waste. We've had a system to provide *ALL* the information a host needs or wants in the IPv4 world for years. Why it's not good enough for IPv6 is beyond me.
You are correct, alone RA does not provide enough for a host to function. We have two mechanisms of providing addressing information to hosts - SLAAC and DHCPv6. How do you, as a network manager, tell hosts which one to use? RA performs this function. Without RA you need to go around all the machines and manually configure how they will discover what addresses to use. That seems a bit silly, and going around every machine is something you have already indicated you don't want to do. RA has two functions - telling your hosts which of SLAAC and DHCPv6 to use for addressing information, and providing addressing information in the case of SLAAC. Also, in the case of SLAAC, it might hint to the client to get additional information from DHCPv6 - DNS servers and so on - in this case it will not get addressing information. Perhaps you have a problem with SLAAC? That is fine, you might not want to use it. Other people *do* want to use it, and RA is the best place to signal which of SLAAC and DHCPv6 a host should use for addressing. Please do not use blanket comments that RA is bad if you actually mean SLAAC. Yes, if we do not have SLAAC then we don't need RA, because hosts will always know to use DHCPv6. However, many people do want SLAAC, so we need RA. If you have an idea for alternative to RA for indicating whether to use SLAAC or DHCPv6 then I encourage you to get involved in the IETF and get your idea written up. If you would like to deprecate/fix SLAAC because you have a problem with it then again, I encourage you to get involved in the IETF. -- Nathan Ward
In message <op.uo5nvrmrtfhldh@rbeam.xactional.com>, "Ricky Beam" writes:
On Mon, 09 Feb 2009 21:11:50 -0500, TJ <trejrco@gmail.com> wrote:
Your routers fail frequently? And does your traffic continue to get forwarded? Perhaps through another router?
More frequently than the DHCP server, but neither are "frequent" events. Cisco's software is not 100% perfect, and when you plug it into moderately unstable things like phone lines (DSL) and cable networks, those little bugs cause reloads -- you'd think they'd have better error handling, but they don't. (I don't buy millions in equipment from Cisco so they don't care about my problems.) While I could use backup links, flip-floping between ISPs with different addresses is not ideal (and that's as true for v6 as v4.)
Why is there a problem with RAs being the first step, possibly including prefix info or possibly just hinting @ DHCPv6?
Because it doesn't fit the needs of *every* network. In fact, it's only "good enough" for very few networks. As such it just adds more useless layers of bloat.
Good. You admit it fits the needs of some networks.
Well, as it stands now the RA isn't useless. ... Also, it is not true in every case that hosts need a "lot more" than an address. In many cases all my machine needs is an address, default gateway and DNS server (cheat off of v4 | RFC5006 | Stateless DHCPv6).
It's useless. It does NOT provide enough information alone for a host to function.
Hogwash. The only thing needed for I used from DHCP on my laptop is router, address and netmask. I actually discard anything else that is offered. RA's meet my needs perfectly fine. In fact they do a better job than DHCP for my needs. I don't trust dns servers returned by dhcp. Lots of them don't offer the level of functionality I require. I run my own recursive resolver to get the level of functionality I require.
In your own words, you need a DNS server. That is NOT provided by RA thus requires yet another system to get that bit of configuration to the host -- either entered manually, DHCPv6, or from IPv4 network configuration (ie. DHCP!) Forcing this BS on the world is a colossal waste. We've had a system to provide *ALL* the information a host needs or wants in the IPv4 world for years. Why it's not good enough for IPv6 is beyond me.
--Ricky
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
On Mon, Feb 9, 2009 at 6:16 PM, Ricky Beam <jfbeam@gmail.com> wrote:
On Fri, 06 Feb 2009 09:39:01 -0500, Iljitsch van Beijnum <iljitsch@muada.com> wrote:
If you want the machine to always have the same address, either enter it manually or set your DHCP server to always give it the same address.
Manual configuration doesn't scale. With IPv4, it's quite hard to make this work with DHCP, but mostly because of a lack of IPv4 addresses. With
'quite hard to make this work'?? what?? have you been making a dhcp server from scratch all these years? Iljitsch, what parts of making static mappings in DHCP, or setting the configuration bits required for dns/default-router/tftp-server/root-partition/wins-server/..... is 'hard to do' in a dhcp server with decently wide use today? (isc dhcpd/windows-dhcp-server)
IPv6 it's easier, but you're still limiting the uptime of your system to that of the DHCPv6 server. Router advertisements is much more robust.
'more robust'... except it doesnt' actually get a device into a usable state without admins walking around to each machine and poking at them randomly. if you have 5 machines that's cool, knock yourself out, if you have 5000 or 50000 you are in a completely different ballpark of work. DHCP servers do this today, the servers pass out all the relevant bits require for dynamic-addressed and static-addressed systems, they can be rebooted, moved, re-addressed, re-homed... all without the masses of clients stopping their work. Why are you filling the discussion with FUD about dhcp servers??
As I read it, you don't want to use DHCP because "it's an other service to fail." Well, what do you think is broadcasting RA's? My DHCP servers have proven far more stable than my routers. (and one of them is a windows server :-)) Most dhcp clients that keep any state will continue using the previously assigned address if the server is unavailable (and nothing else is using it.) Configuring a static address in a DHCP server is a pretty trivial task.
thank you Mr. Beam.
I have a lot of problems with DHCP and most people don't _need_ it. Still,
can you explain how 'most people don't need it'?? is that because most people have an admin to go configure their DNS servers in their resolver config?? Consumer Internet users are a great example of this, if necessary an ISP can pass out new DNS servers, and in 8-10 days easily remove the old DNS servers from the network, or move them to another place in the network seemlessly without having to touch each consumer device. Why would anyone NOT want that?? what replaces that option in current RA deployments?
very many people _want_ it and some people do in fact need it. I have no problem with that, as long as it doesn't lead to the situation where I have to run it.
no, you don't today have to run it... but why are you arguing against the fact that admins at enterprises and ISP's have been making this very clear argument for equal functionality to what's available today? -Chris
Why would anyone NOT want that?? what replaces that option in current RA deployments?
One nit - I like to differentiate between the presence of RAs (which should be every user where IPv6 is present) and the use of SLAAC (RA + prefix). Right now - Cheat off of IPv4's config. (Lack of DHCPv6 client-side support, and lack of DNS v6 transport (WinXP), necessitate this) Hopefully soon - RFC5006. Around the same timeframe - DHCPv6 (stateful or stateless, doesn't matter).
On Mon, Feb 9, 2009 at 9:47 PM, TJ <trejrco@gmail.com> wrote:
Why would anyone NOT want that?? what replaces that option in current RA deployments?
One nit - I like to differentiate between the presence of RAs (which should be every user where IPv6 is present) and the use of SLAAC (RA + prefix).
Sure, but... RA is necessitated by the initial decision to use it and NOT support something akin to the bootp/dhcp sequence that v4 has. This could, it seems to me, be done... but since RA is there, it's not BAD to use it for prefix/default-route/ip-address it's just not anywhere near complete.
Right now - Cheat off of IPv4's config. (Lack of DHCPv6 client-side support, and lack of DNS v6 transport (WinXP), necessitate this)
agreed. -Chris
On 10/02/2009, at 3:20 PM, Christopher Morrow wrote:
IPv6 it's easier, but you're still limiting the uptime of your system to that of the DHCPv6 server. Router advertisements is much more robust.
'more robust'... except it doesnt' actually get a device into a usable state without admins walking around to each machine and poking at them randomly. if you have 5 machines that's cool, knock yourself out, if you have 5000 or 50000 you are in a completely different ballpark of work. DHCP servers do this today, the servers pass out all the relevant bits require for dynamic-addressed and static-addressed systems, they can be rebooted, moved, re-addressed, re-homed... all without the masses of clients stopping their work.
I believe you are mis-interpreting Iljitsch's comments. I believe he is talking about SLAAC, you are talking about *no* DHCPv6. The difference is, SLAAC can still use DHCPv6 to get configuration information. If the DHCPv6 server goes away when using SLAAC for addressing, configuration information is already there.
I have a lot of problems with DHCP and most people don't _need_ it. Still,
can you explain how 'most people don't need it'?? is that because most people have an admin to go configure their DNS servers in their resolver config?? Consumer Internet users are a great example of this, if necessary an ISP can pass out new DNS servers, and in 8-10 days easily remove the old DNS servers from the network, or move them to another place in the network seemlessly without having to touch each consumer device.
Why would anyone NOT want that?? what replaces that option in current RA deployments?
Again, this seems to be confusion with SLAAC vs. "no DHCPv6 what so ever". I could be wrong though - I don't want to be putting words in to Iljitsch's mouth. -- Nathan Ward
Five things? Really? My DHCP server hands out the following things to its clients: Default Route DNS Servers Log host Domain Name (or, our case, the sub-domain for the office) NIS Domain NIS Servers NTP Server WINS Servers SMTP Server POP Server NNTP Server Domain suffix search orders. All these useful and handy things that my Windows, Unix (Irix and Solaris), Linux, and FreeBSD clients all need some portion of, in one place where I configure and control it. Static reservations are handled here as well and it ties into the DNS servers to dynamically update forward and reverse as needed (which is rare since even non static allocations don't tend to change). Having to deal with configuration and control of this in multiple places is only going to make the sysadmins of the world hate you. I don't work in an ISP anymore, and I haven't had to deal with BGP/OSPF in almost a decade now other than for some minor internal routing, but you know what? I still have a network with several hundred hosts on it that have to be managed, and DHCP makes life easy for a large chunk of it. We're just one little piece of a larger pie. Our Corporate Overlords are eighty thousand users on seven continents with far more than a 1:1 end user to host ratio. Jamie -----Original Message----- From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] Sent: Thursday, February 05, 2009 5:42 PM To: Ricky Beam Cc: NANOG list Subject: Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space(IPv6-MW)] On 5 feb 2009, at 22:44, Ricky Beam wrote:
A single /64 isn't enough for a home user, because their gateway is a router and needs a different prefix at both sides. Users may also want to subnet their own network. So they need at least something like a /60.
Mr. van B, your comments would be laughable if they weren't so absurdly horrific.
That doesn't change the fact that users would be quite constrained by only having a /64 for their internal network.
I've lived quite productively behind a single IPv4 address for nearly 15 years.
So you were already doing NAT in 1994? Then you were ahead of the curve.
I've run 1000 user networks that only used one IPv4 address for all of them.
But how is that relevant for the discussion at hand? Is your point that if 1000 users can share an IPv4 address, 1000 users should share an IPv6 address? How would that make sense? Sharing addresses comes with significant downsides. (Like having to port map services running on hosts on the inside.) Sharing one address with 1000 active users comes with even more downsides. (There are applications that need more than 64 ports so the port number space becomes a limitation.) IPv6 was specifically designed to provide an enormous amount of address space, so accepting the limitation of using one address for a large number of users means foregoing a prime feature of IPv6--for no reason that I can see.
Yet, in the new order, you're telling me I need 18 billion, billion addresses to cover 2 laptops, a Wii, 3 tivos, a router, and an access point?
The logic is like this. 1. You need more than one. 2. You don't want to change the number often (or at all) 3. What is a number that is so large that it will always be enough? Answer: the size of a MAC address. 4. How large are MAC addresses? Answer: we have technologies that have 64-bit MAC addresses. So we use 64 bits to number subnets. Now of course that seems wasteful, but those 128-bit addresses are carried in all packets anyway, and at least with 64-bit subnet sizes you get some use out of them because you know subnets are always large enough and you get to generate an address from a prefix through a function that gives you the same address without requiring anyone to remember that address, which is also useful. Now if you want to argue that IPv6 should have had 48, 53 or 64 bit addresses, that's fine. But I have to warn you that that ship sailed almost 15 years ago. (My take: they should have been variable length.)
This is the exact same bull**** as the /8 allocations in the early days of IPv4.
Oh no. A /8 is only 16777216 addresses. A /48 for an end-user organization is 1208925819614629174706176 addresses. Or, more relavant: a /8 is almost 0.5% of the IPv4 address space. A / 48 is 0.000000000003% of the currently defined global unicast IPv6 address space.
The idea of the "connected home" is still nowhere near *that* connected;
It took us 15 years to get this far with IPv6. There is no IPv7 on the horizon currently, so even if we start that tomorrow we'll have to get by with IPv6 (and IPv4...) until about 2024. I'm pretty sure we'll be *that* connected by that time.
no matter how many toys you have in your bathroom, it doesn't need a /96 of it's own. (which is an entire IPv4 of it's own.)
Like I explained, we count "0, 1, many" where the IPv6 definition of "many" happens to be 2^64. This is obviously not the single answer that is right in all cases. But the point is that there are reasons why it was a bad idea to make it less than that and no reasons that reasonably required it to be less.
Why do people avoid and resist IPv6... because it was designed with blind ignorance of the history of IPv4's mistakes (and how we *all* run our IPv4 networks.) Dooming us to repeating ALL those mistakes again.
IPv6 changes too much but it doesn't fix enough. It would be good if it didn't change much but fixed a lot, but unfortunately, that wasn't to be.
Exhibit A: With IPv6 Address Autoconfiguration (tm) (patent pending), you don't need DHCP. *face plant* The IPv4 mistake you've NOT learned from here is "rarp". DCHP does far more than tell a host was address it should use.
An IPv4 DHCP server gives me five things: an address, a prefix length, a default gateway, DNS addresses and a domain. A DHCPv6 server _can_ give me an address but I don't need it because I can generate it myself (with a little help from my friends the routers), it can't give me a prefix length or default gateway, so I still need router advertisements for those (may as well hardcode that /64 now because there is no reasonable way to get something else to work) and I don't need the domain because it's always muada.com anyway. So the only thing missing is the DNS addresses, but RFC 5006 specifies how to add this information to router advertisements. So I have no need for DHCPv6*. If someone else has, good for them and good luck with that. As long as I don't have to run a DHCPv6 server just to suck up all the broadcasts from DHCPv6 clients that are looking for DHCPv6 servers in my network. Please pick up after your dog. * except for prefix delegation to routers.
On Fri, Feb 6, 2009 at 10:22 AM, Jamie Bowden <jamie@photon.com> wrote:
Five things? Really? My DHCP server hands out the following things to its clients:
as I've said a few times now, reason #775 that autoconf is a broken and non-useful 'gadget' for network operators. There is a system today that does lots of client-conf (including the simple default-route + dns-server) called DHCP, there MUST be a similarly featured system in the 'new world order' of ipv6. This really is non-negotiable, why are people still holding out hope that autoconf is 'enough' when users and operators have so clearly said otherwise? -Chris
as I've said a few times now, reason #775 that autoconf is a broken and non- useful 'gadget' for network operators. There is a system today that does lots of client-conf (including the simple default-route + dns-server) called DHCP, there MUST be a similarly featured system in the 'new world order' of ipv6.
This really is non-negotiable, why are people still holding out hope that autoconf is 'enough' when users and operators have so clearly said otherwise?
There IS a similarly featured system. Why is it so hard to accept that in MANY cases SLAAC is enough (especially when RFC5006 is more widely supported, or while IPv4 is still around to cheat off of (glaring at WinXP)) ... and when it isn't enough, or when you feel like doing more DHCPv6 is there waiting for you? Almost no one is arguing that DHCPv6 can't exist, shouldn't exist, etc. Perhaps with the exception of Apple, that is - and that is still OK! I certainly see value in DHCPv6, but I see value in SLAAC as well. I don't want to force anyone to not do DHCPv6, why do others want to force me to do DHCPv6? Can't we all just get along?
Five things? Really? My DHCP server hands out the following things to its clients:
Default Route DNS Servers Log host Domain Name (or, our case, the sub-domain for the office) NIS Domain NIS Servers NTP Server WINS Servers SMTP Server POP Server NNTP Server Domain suffix search orders.
All these useful and handy things that my Windows, Unix (Irix and Solaris), Linux, and FreeBSD clients all need some portion of, in one place where I configure and control it.
Super, great and wonderful. Keep doing so. But I think Iljitsch's point is that I shouldn't have to run DHCPv6 when I can get everything I need from SLAAC. In other words, what is wrong with having two complimentary pieces: Router: Sends out RAs, gets hosts a default gateway ... and maybe a prefix ... and maybe a DNS server DHCPv6: Hands out other information (DNS server) and maybe addresses upon request from host
Having to deal with configuration and control of this in multiple places is only going to make the sysadmins of the world hate you.
Sorry, are your routers not getting any sort of configuration now? If it is a Cisco box once you give that Ethernet interface an address it will send out RAs by default, no extra work. In fact, less work - you don't need to configure your DHCPv6 server with the default gateway addresses of every subnet.
In message <op.uoweo8dxtfhldh@rbeam.xactional.com>, "Ricky Beam" writes:
On Thu, 05 Feb 2009 10:25:44 -0500, Iljitsch van Beijnum <iljitsch@muada.com> wrote:
On 5 feb 2009, at 1:16, Patrick W. Gilmore wrote:
I guess I was thinking about v4 modems which do not get a subnet, just an IP address. If we really are handing out a /64 to each DSL & Cable modem, then we may very well be recreating the same problem.
IPv4 thinking.
A single /64 isn't enough for a home user, because their gateway is a router and needs a different prefix at both sides. Users may also want to subnet their own network. So they need at least something like a /60.
This is not a "maybe", Mr. Gilmore. It's repeating the same mistakes of IPv4.
Mr. van B, your comments would be laughable if they weren't so absurdly horrific. I've lived quite productively behind a single IPv4 address for nearly 15 years. I've run 1000 user networks that only used one IPv4 address for all of them.
Good for you. You don't need what NAT breaks. The rest of us are sick and tired of a artificially crippled network that NAT brings and all the additional costs associated with trying to talk with someone behind a NAT.
I have 2 private /24's using a single public IPv4 address right now -- as they have been for 6+ years. Yet, in the new order, you're telling me I need 18 billion, billion addresses to cover 2 laptops, a Wii, 3 tivos, a router, and an access point? Did we suddenly jump 20 years into the past? This is the exact same bull**** as the /8 allocations in the early days of IPv4. The idea of the "connected home" is still nowhere near *that* connected; no matter how many toys you have in your bathroom, it doesn't need a /96 of it's own. (which is an entire IPv4 of it's own.)
No it doesn't need that many address. No one has ever said that it does. Does it really matter that 64 bits are set aside for the local part of the IPv6 address as long as there is enough address space for everyone to get the networks they need? By your own admission it does need multiple networks however. The address allocation policies are design to give everyone the networks that they need.
Why do people avoid and resist IPv6... because it was designed with blind ignorance of the history of IPv4's mistakes (and how we *all* run our IPv4 networks.) Dooming us to repeating ALL those mistakes again. Exhibit A: With IPv6 Address Autoconfiguration (tm) (patent pending), you don't need DHCP. *face plant*
So all of us running IPv6 networks using stateless autoconf are using something that does not work? BTW stateless autoconf and DHCP are complementry technologies.
The IPv4 mistake you've NOT learned from here is "rarp". DCHP does far more than tell a host was address it should use. (yes, I've called for the IPng WG member's execution, reanimation, and re-execution, several times.)
--Ricky
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
On Thu, 5 Feb 2009, Ricky Beam wrote:
telling me I need 18 billion, billion addresses to cover 2 laptops, a Wii, 3 tivos, a router, and an access point?
You have more computing power in your house than the Fortune 500 did 40 years ago to manage their entire billing, payroll etc. They had thousands of people and paid millions of dollars per year just to make sure that scarce resource was not wasted. You use it for watching TV shows and browsing the web a few hours per day. As others have pointed out giving every person on the planet a /56 and every business a /48 is only going to take up 0.01% of the total IP space. Allocating 0.01% of space to an "experiment in abundance" which will probably turn out to be enough space than will ever be needed this century seems a good risk to me. Sure we could have allocated just 0.00001% of space to the experiment instead but then plug-and-play might not work out of the box or people would have to apply and pay for larger network spaces or I'd only get one network in my house ( and never get my SIP phone to work cause of NAT ). You may find this article interesting ( especially the first page ): "The sysadmin’s mantra: Manage time, think ‘abundance’ and softly does it" http://www.computerworld.com.au/article/272429/sysadmin_mantra_manage_time_t... -- Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT.
Some devices will refuse to work if you subnet smaller than a /64. (Yes, poorly designed, etc.)
Actually, no - not poorly designed. The spec says it must be a /64 (excluding those starting with 000 binary) so that is what devices (rightfully) expect. Ref: http://tools.ietf.org/html/rfc4291#section-2.5.1 /TJ
TJ wrote:
Some devices will refuse to work if you subnet smaller than a /64. (Yes, poorly designed, etc.)
Actually, no - not poorly designed. The spec says it must be a /64 (excluding those starting with 000 binary) so that is what devices (rightfully) expect. Ref: http://tools.ietf.org/html/rfc4291#section-2.5.1
I was just trying to head off the flood of "poorly designed" comments last time I said such a thing on a different list. ;) I find /64 convenient because it ends on a nice boundary out of my /48 and for my purposes it's more than enough space. The only annoyance I've come across was my Cisco devices will only accept an EUI-64 address as a host address in an ACL. Not a big deal though. ~Seth
IPv4-style utilization ratios do make some sense under IPv6, but not at the address level - only at the network level.
First, it was (mostly) a joke.
Second, where did you get 4 users per /64? Are you planning to hand each cable modem a /64?
At the least. Some would say a /56 is more appropriate. So, one /64 for your desktop and one /64 for your open wireless. :-) Mike
On Mon, Feb 2, 2009 at 9:35 PM, Patrick W. Gilmore <patrick@ianai.net>wrote:
Except the RIRs won't give you another /48 when you have only used one trillion IP addresses.
Of course they will! A /48 is only the equivalent of 65536 "networks" (each network being a /64). Presuming that ISPs allocate /64 networks to each connected subscriber, then a /48 is only 65k subscribers, or say around a maximum of 200k IP addresses in use at any one time (presuming no NAT and an average of 3-4 IP-based devices per subscriber)
IPv4-style utilization ratios do make some sense under IPv6, but not at the address level - only at the network level.
First, it was (mostly) a joke.
Second, where did you get 4 users per /64? Are you planning to hand each cable modem a /64?
No, we should hand each home a /56 (or perhaps a /48, for the purists out there) - allowing for multiple segments (aka subnet, aka links, etc.). Note - the actual number of hosts is irrelevant; the 64 bits on the host side of the address are not meant to encourage 18BB hosts/segment. Oh, and utilization should be based on /56s anyway. /TJ
TJ wrote:
No, we should hand each home a /56 (or perhaps a /48, for the purists out there) - allowing for multiple segments (aka subnet, aka links, etc.). If there are, say, 250-500 million broadband services in the world (probably more) then, if every ISP followed best practise for IPv6 address allocation, (sparse, bits for infrastructure, whatever etc) then what percentage of the space do we have left if we hand out /56 or /48s?). Taking into account the space already carved off for link local, private addressing, US Military etc.
Has anyone done some analysis of what this might look like? Especially with growth etc. MMC -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc@internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
Has anyone done some analysis of what this might look like? Especially with growth etc.
Sure, probably lots of people lots of times. Off the top of my head, using some current/common allocations sizes: Current "Global Unicast" space --> 2000::/3 An "average" RIR --> /12 an "average" ISP --> /32 an average enterprise --> /48 an average home user --> /56 So, "the current IPv6 world" (2000::/3) can support 512 standard RIR sized allocations. Each standard RIR can support 1M standard ISPs. Each standard ISP can support 64K enterprises or 16M standard home-users, or some combination thereof. So - How much do we want held in reserve? How "flexibly" (ref RFC3531) are we allocating our addresses? How many total (enterprise | home) clients do we want to support? Off the cuff, let's say we use left-most (sparse) allocation and only hit 50% efficiency (keeping the right-most bit totally in reserve!) ... If I am an ISP, and I have 300M home users (/56s) I just need a /26, and that actually gives me a lot of room for more clients (like 200M more). So - what was the problem again? Let's make it even more interesting - let's say I am an ISP, I am allocating /48s, and I need to support - say - 6B assignments for every person in the world + 2B for every organization in the world (#s chosen arbitrarily, feel free to add another bit if it makes you feel better). Bearing in mind that this means every single person and organization has 64k subnets, each of which contains "as many hosts as is appropriate", and all of these are globally routable ... I "just" need a /15 to cover this absolute worst case. Heck, let's make it /14 for good measure. So now each standard RIR can "only" support 4 of this size service provider, but we still have 512 RIR sized allocations. If the individuals got /56s instead these numbers getting even bigger ... So - what was the problem again? Oh, and this is just from the 2000::/3 range ... next up, 4000::/3 ... 6000::/3, 8000::/3, a000::/3, c000::/3. And if we feel like we burned through 2000::/3 too fast at some point in the future, maybe we revisit the rules around the time we start thinking about allocating from 4000::/3? (Or "skip one", and star the new rules with 6000::/3 ... I am not picky). Note, I am _NOT_ saying we should be careless or cavalier about address allocation, just saying we don't live in a constrained situation. And if there is a choice to be made between scalability/flexibility/summarization'ability (is that a word?) and strict efficiency ... the efficiency loses. /TJ PS - Yes, 4.3B seemed really big at one point ... but seriously, do the above numbers not _really_ sound big enough?
On 5/02/2009, at 3:09 PM, Matthew Moyle-Croft wrote:
No, we should hand each home a /56 (or perhaps a /48, for the purists out there) - allowing for multiple segments (aka subnet, aka links, etc.). If there are, say, 250-500 million broadband services in the world (probably more) then, if every ISP followed best practise for IPv6 address allocation, (sparse, bits for infrastructure, whatever etc)
TJ wrote: then what percentage of the space do we have left if we hand out /56 or /48s?). Taking into account the space already carved off for link local, private addressing, US Military etc.
Has anyone done some analysis of what this might look like? Especially with growth etc.
My addressing plan works like this: ISP gets /32, 2001:db8::/32 - 2001:db8:0::/48 = ISP use -- 2001:db8:0:0::/64 = infrastructure --- 2001:db8:0:0:0:0:0::/112 = loopbacks ( 65536 ) --- 2001:db8:0:0:1:0:0::/112 through 2001:db8::ffff:ffff:ffff:0/112 = / 112 link nets between ISP routers ( 281474976710656 ) -- 2001:db8:0::/64 through 2001:db8:0:ffff::/64 = ISP networks, ie. servers, etc. - 2001:db8:1::/64 through 2001:db8:ffff:ffff::/64 = customer networks. Assuming the above, we have 65535 /48s available to customers, or 16,711,680 /56s. The "ISP use" /48 burns 256 /56s, or potential customers. So, like burning a /24 for the entire ISP operation. So, if you have more than 65K business customers, get more than a /32. If you have more than 16M residential or small business customers, get more than /32. The above plan puts the addresses you type lots (loopbacks, link nets) on the shortest addresses you have - you can use the zero compression :: thing. These are also the addresses that cause the most trouble if fat fingered, so shorter addresses leave less room for error. In addition, the entire first /64 (loopbacks, link nets) should never really receive packets from outside the network. Drop in an ACL. Modification to the above plan is to use /64s for link nets between ISP routers, if you are worried about compatibility issues. You now have a trade off between 65k ISP server networks, and 65k link nets. Let's say 32k for each. -- Nathan Ward
--On onsdag, onsdag 4 feb 2009 19.02.56 -0500 "Patrick W. Gilmore" <patrick@ianai.net> wrote:
Second, where did you get 4 users per /64? Are you planning to hand each cable modem a /64?
Telia got their /20 based on calculations where they give every customer a /48. Every apartment in every highrise gets 2^16 networks. I think that /56 or /52 is a more appropriate allocation per broadband subscriber. -- Måns Nilsson M A C H I N A ... he dominates the DECADENT SUBWAY SCENE.
On Wed, 4 Feb 2009 15:56:44 -0800, Scott Howard <scott@doc.net.au> wrote:
On Mon, Feb 2, 2009 at 9:30 PM, Anthony Roberts <nanog@arbitraryconstant.com> wrote:
It has been my experience that when you give someone a huge address space to play with (eg 10/8), they start doing things like using bits in the address as flags for things. Suddenly you find yourself using a prefix that should enough for a decent sized country in a half-rack.
Which is, of course, a core design philosophy for IPv6. Stateless autoconfig relies on the fact that each network will be allocated 2^64 address.
I'm actually pretty happy about /64's, they take away all the hand-wringing over how big a network should be, and they make manually configured server addresses easier to remember through the use of big regions of 0s. I was thinking more about wasting prefix bits. -Anthony
Valdis.Kletnieks@vt.edu wrote:
On Tue, 03 Feb 2009 11:25:40 +0900, Randy Bush said:
<snip>
Not quite.. 2^96 = 79228162514264337593543950336 2^128-2^32 = 340282366920938463463374607427473244160 not quite. let's posit 42 devices on the average lan segment (ymmv).
42*(2^64) = 774763251095801167872
Let's face it - they're going to have to come up with much more creative $200/hour chucklehead consultants to burn through that much anytime soon.
<snip>
Anybody feel like starting a pool for when we'll see a posting to NANOG about somebody who's managed to burn through a /32?
two of them will separately just assign fc00::/7 to a network instead of following the instructions.
Just for the record, the original post was in reference to use of non-RFC1918 space on an *air-gapped* network. --Trey
Let's face it - they're going to have to come up with much more creative $200/hour chucklehead consultants to burn through that much anytime soon.
Anybody feel like starting a pool for when we'll see a posting to NANOG about somebody who's managed to burn through a /32?
++----------------------------------------------------------------------------++ Kingfisher Operations Trey Darley - Principal
participants (51)
-
Andy Davidson -
Anthony Roberts -
Bill Stewart -
Bjørn Mork -
Christopher Morrow -
Daniel Senie -
David W. Hankins -
Deepak Jain -
Heather Schiller -
Howard C. Berkowitz -
Iljitsch van Beijnum -
Jack Bates -
James R. Cutler -
Jamie Bowden -
Joe Abley -
Joe Loiacono -
Joe Maimon -
Joel Jaeggli -
John Osmon -
John Schnizlein -
Johnny Eriksson -
Mark Andrews -
Matthew Kaufman -
Matthew Moyle-Croft -
Michael Hallgren -
Michael K. Smith - Adhost -
Mikael Abrahamsson -
Mohacsi Janos -
Mr. James W. Laferriere -
Måns Nilsson -
Nathan Ward -
Owen DeLong -
Patrick W. Gilmore -
Paul Jakma -
Paul Timmins -
Paul Vixie -
Randy Bush -
Ricky Beam -
Robert D. Scott -
Scott Howard -
Seth Mattinen -
Simon Lyall -
Stephen Kratzer -
Stephen Sprunk -
sthaug＠nethelp.no -
Sven-Haegar Koch -
Tim Durack -
TJ -
Tony Finch -
Trey Darley -
Valdis.Kletnieks＠vt.edu