Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
Anthony Roberts wrote:
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.
Why do we want to prevent people using NAT? If people choose to use NAT, then I have no issue with that. This anti-NAT zealotism is tiring and misplaced.
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.
And ARP tables are propogated around networks? No, they're local to a router. 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 Thu, 05 Feb 2009 11:41:01 +1030, Matthew Moyle-Croft <mmc@internode.com.au> wrote:
And ARP tables are propogated around networks? No, they're local to a router.
I don't think there's any need for the ISP's routers to advertise all the prefixes they delegate. They'll advertise the /48 or whatever it is, and then delegate chunks out of that.
Anthony Roberts wrote:
I don't think there's any need for the ISP's routers to advertise all the prefixes they delegate. They'll advertise the /48 or whatever it is, and then delegate chunks out of that.
My apologies for not being clear: As I posted just before in reply to MarkA - I'm hoping that for the MAJORITY of customers that I can use PD and dynamic /64s (or whatever) local to a BRAS. My FEAR is that people ("customers") are going to start assuming that v6 means their own static allocation (quite a number are assuming this). This means that I have a problem with routing table size etc if I have to implement that. I'm still not convinced though that, given DHCPv6 is going to be a reality for DNS assignment etc, that stateless autoconfig is needed and thus /64 doesn't have to be the smallest we assign. 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
Matthew Moyle-Croft wrote:
Anthony Roberts wrote:
I don't think there's any need for the ISP's routers to advertise all the prefixes they delegate. They'll advertise the /48 or whatever it is, and then delegate chunks out of that.
My apologies for not being clear:
As I posted just before in reply to MarkA - I'm hoping that for the MAJORITY of customers that I can use PD and dynamic /64s (or whatever) local to a BRAS. My FEAR is that people ("customers") are going to start assuming that v6 means their own static allocation (quite a number are assuming this). This means that I have a problem with routing table size etc if I have to implement that.
Well, it is static, but like most static IP services offerd by an ISP, if you leave you can't take your addresses with you. Even with DSL from AT&T if you move locations you get a different subnet. ~Seth
Seth Mattinen wrote:
Well, it is static, but like most static IP services offerd by an ISP, if you leave you can't take your addresses with you. Even with DSL from AT&T if you move locations you get a different subnet.
The issue is multiple POPs in a geographic region where customers could connect to either- if you have those and want them to work in adversity then you've got a problem as you need to allow the static addresses to propogate around. When that number is small then it's not a problem, but when you've got it large scale then you have a routing problem. This is my fear. 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 5/02/2009, at 2:28 PM, Matthew Moyle-Croft wrote:
Anthony Roberts wrote:
I don't think there's any need for the ISP's routers to advertise all the prefixes they delegate. They'll advertise the /48 or whatever it is, and then delegate chunks out of that.
My apologies for not being clear:
As I posted just before in reply to MarkA - I'm hoping that for the MAJORITY of customers that I can use PD and dynamic /64s (or whatever) local to a BRAS. My FEAR is that people ("customers") are going to start assuming that v6 means their own static allocation (quite a number are assuming this). This means that I have a problem with routing table size etc if I have to implement that.
In my opinion, if they want static, they get business grade services, and get a /48. Or maybe a /56 over DSL perhaps. And they pay more for it. Otherwise they get PD like everybody else. The ability is there *now* for you to manage this expectation and say to customers that they are dynamic. Exploit it.
I'm still not convinced though that, given DHCPv6 is going to be a reality for DNS assignment etc, that stateless autoconfig is needed and thus /64 doesn't have to be the smallest we assign.
Dynamic PD requires SLAAC, unless your customers have say 30s DHCPv6 lease times on their DHCPv6 servers. DSL reconnects, gets new IPv6 prefix, sends RA messages internally, hosts renumber and mark the existing prefix as deprecated until it expires. The alternative is waiting for hosts to do a DHCPv6 query to get a new address. That is sub-optimal. -- Nathan Ward
In message <498A40C1.8060702@internode.com.au>, Matthew Moyle-Croft writes:
Anthony Roberts wrote:
I don't think there's any need for the ISP's routers to advertise all the prefixes they delegate. They'll advertise the /48 or whatever it is, and then delegate chunks out of that.
My apologies for not being clear:
As I posted just before in reply to MarkA - I'm hoping that for the MAJORITY of customers that I can use PD and dynamic /64s (or whatever) local to a BRAS.
My FEAR is that people ("customers") are going to start assuming that v6 means their own static allocation (quite a number are assuming this). This means that I have a problem with routing table size etc if I have to implement that.
I'm still not convinced though that, given DHCPv6 is going to be a reality for DNS assignment etc, that stateless autoconfig is needed and thus /64 doesn't have to be the smallest we assign.
All IPv6 address assignments are leases. Whether you get the address from a RIR, LIR or ISP. The lease may not be renewed when it next falls due. You may get assigned a different set of addresses at that point. You should plan accordingly. The only difference is the mechanisms used to assign the leases and the probability that you may have to renumber when the lease falls due. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
My FEAR is that people ("customers") are going to start assuming that v6 means their own static allocation (quite a number are assuming this). This means that I have a problem with routing table size etc if I have to implement that.
Then work with them to break them of this dis-illusion.
I'm still not convinced though that, given DHCPv6 is going to be a reality for DNS assignment etc, that stateless autoconfig is needed and thus /64 doesn't have to be the smallest we assign.
Yes and no. You sound like you are of the belief that SLAAC is bad / deficient - while it may not be perfect, some are big fans of its ease of use ATLEAST in certain deployment models.
In a message written on Thu, Feb 05, 2009 at 11:58:33AM +1030, Matthew Moyle-Croft wrote:
My FEAR is that people ("customers") are going to start assuming that v6 means their own static allocation (quite a number are assuming this). This means that I have a problem with routing table size etc if I have to implement that.
Customers don't want static addresses. They want DNS that works, with their own domain names, forward and reverse. They want renumbering events to be infrequent, and announced in advance. They want the box the cable/dsl/fios provider to actually work, that is be able to do really simple stuff without having to buy another stupid box to put behind it. None of these require static, and in fact I'd think it would be easier to get it right than it would be to do statics for most providers. But, I must be wrong, since the only solution virtually every provider offers is to "move up" to "a static IP". -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
Leo Bicknell wrote:
In a message written on Thu, Feb 05, 2009 at 11:58:33AM +1030, Matthew Moyle-Croft wrote:
My FEAR is that people ("customers") are going to start assuming that v6 means their own static allocation (quite a number are assuming this). This means that I have a problem with routing table size etc if I have to implement that.
Customers don't want static addresses.
Customers want many different things. Customers don't think of their networks at home or in their offices as part of an ISP network. They think of it as an island that they control and run and which they buy connectivity to the internet to. They want flexibility and not the "evil ISP" telling THEM what to do or making them spend money on their IT consultants to change things when an ISP wants to renumber.
They want DNS that works, with their own domain names, forward and reverse.
Yep, but many want to run it themselves, independantly of an ISP.
They want renumbering events to be infrequent, and announced in advance.
Where infrequent = never.
They want the box the cable/dsl/fios provider to actually work, that is be able to do really simple stuff without having to buy another stupid box to put behind it.
Well, we let them chose here in AU ...
None of these require static, and in fact I'd think it would be easier to get it right than it would be to do statics for most providers. But, I must be wrong, since the only solution virtually every provider offers is to "move up" to "a static IP".
I think some customers would like us to spend money running DNS for them for free, but most who care want to do it independently of us. 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 Feb 4, 2009, at 6:19 PM, Leo Bicknell wrote:
In a message written on Thu, Feb 05, 2009 at 11:58:33AM +1030, Matthew Moyle-Croft wrote:
My FEAR is that people ("customers") are going to start assuming that v6 means their own static allocation (quite a number are assuming this). This means that I have a problem with routing table size etc if I have to implement that.
Customers don't want static addresses.
I completely disagree.
They want DNS that works, with their own domain names, forward and reverse.
That's also necessary, but, it's not the full solution.
They want renumbering events to be infrequent, and announced in advance.
You need to define infrequent. Renumbering more than once a decade would be problematic and costly for me. There are lots of places where my static address is known in configurations that I do not necessarily control and getting those places all updated in sync. with some providers arbitrary change is, well, problematic. Sure, most customers aren't quite in that situation, but, more and more having to have your specific IP added to some firewall somewhere (or more than one) is a valid concern. With IPv6, this challenge will increase, not decrease. As such, I don't see non-static addresses meeting everyone's needs.
They want the box the cable/dsl/fios provider to actually work, that is be able to do really simple stuff without having to buy another stupid box to put behind it.
There is that, yes.
None of these require static, and in fact I'd think it would be easier to get it right than it would be to do statics for most providers. But, I must be wrong, since the only solution virtually every provider offers is to "move up" to "a static IP".
Actually, statics aren't any harder than dynamics if you do your providing right. In IPv4, statics are complicated by the fact that there is a shortage of addresses and so providers try to recycle. However, in always on broadband services, statics really don't take any more effort if the provider does decent planning, and, providers seem to be able to get away with charging huge premiums for them. I doubt providers could charge huge premiums for just making the basic stuff work, and, they seem to get paid anyway without doing so. (*note, Comcast is not getting paid by me pending them actually getting some things right, but, I seem to be the exception, not the rule). Owen
Leo writes:
Customers don't want static addresses.
They want DNS that works, with their own domain names, forward and reverse.
They want renumbering events to be infrequent, and announced in advance.
They want the box the cable/dsl/fios provider to actually work, that is be able to do really simple stuff without having to buy another stupid box to put behind it.
None of these require static, and in fact I'd think it would be easier to get it right than it would be to do statics for most providers. But, I must be wrong, since the only solution virtually every provider offers is to "move up" to "a static IP".
I'm one of the geeky fringe here, obviously, but it's hard for my nameservers at home to not be static IPed be it IPv4 or v6. There are plenty of possible solutions, but they all involve more effort by the ISP or DNS provider... I and they can put in that effort, but just provisioning me statics is a lot easier, and that's what everyone has done so far. Nothing about the IPv6 transition on the transport end changes the provisioning effort / logistics / technical support difficulty issues associated with this. If you believe that geek houses are enough of an outlier to not worry about, consider the million or so internet connected small businesses who do their own DNS... Perhaps there are better ways to do all of this from the start. But IPv6 is not helping any of the ways we have evolved to deal with it. Perhaps it's time for some actual network operators and equipment vendors to go talk on the side about IPv7 and making our lives easier rather than harder. I urge everyone who is involved in the back-room "bring tar and feathers to next IETF meeting" discussions to do this instead. I really don't care how many bits are wasted on what - I want DNS, routing, endpoint mobility, multihoming, NAT, et al to work. If that means bigger packets or wasted address space so be it. We have pipe bandwidth and Moore's Law growth to work with here. Having to patch the net together for the next decade with baling wire and string because a bunch of non-operators got to set IPv6 up to be a more perfect way forward is not scaling. And 20 years between protocol design and rollout is absurd and insulting. -george william herbert gherbert@retro.com
George William Herbert wrote: <snip beautiful post>
Perhaps there are better ways to do all of this from the start. But IPv6 is not helping any of the ways we have evolved to deal with it.
<snip great ending> IPv6 does just fine with dynamic addressing and with static addressing. I'm not sure what your problem is. An ISP can still assign static addressing, and in fact, most ISP layouts will be *more* static than they were with IPv4. However, it will depend on their implementations and what they want. As was explained to me, there were many BIG providers definitely putting their $0.02 in concerning IPv6. That's actually where full blown IPv6 comes in, btw. Something to do with DOCSIS from what I understand; though that's way out of the scope of my telco self. I play with copper. Jack
In message <498A3CA5.6060801@internode.com.au>, Matthew Moyle-Croft writes:
Anthony Roberts wrote:
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.
Why do we want to prevent people using NAT? If people choose to use NAT, then I have no issue with that.
This anti-NAT zealotism is tiring and misplaced.
NAT's break lots of things and increase the development costs of every piece of network based software being written. If we could get a true accounting of the extra cost imposed by NAT's I would say it would be in the trillions of dollars. NAT's are a necessary evil in IPv4. If every node that currently communicates to something the other side of a NAT was to have a global address then we would have already run out of IPv4 addresses. NAT's are not a necessary evil in IPv6. Just stop being scared to renumber. Addresses are not forever and when you design for that renumbering get easier and easier. For everything else there are alternate solutions.
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.
And ARP tables are propogated around networks? No, they're local to a router.
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
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
Mark Andrews wrote:
In message <498A3CA5.6060801@internode.com.au>, Matthew Moyle-Croft writes:
Anthony Roberts wrote:
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.
Why do we want to prevent people using NAT? If people choose to use NAT, then I have no issue with that.
This anti-NAT zealotism is tiring and misplaced.
NAT's break lots of things and increase the development costs of every piece of network based software being written.
If we could get a true accounting of the extra cost imposed by NAT's I would say it would be in the trillions of dollars.
NAT's are a necessary evil in IPv4. If every node that currently communicates to something the other side of a NAT was to have a global address then we would have already run out of IPv4 addresses.
NAT's are not a necessary evil in IPv6. Just stop being scared to renumber. Addresses are not forever and when you design for that renumbering get easier and easier.
For everything else there are alternate solutions.
Far too many people see NAT as synonymous with a firewall so they think if you take away their NAT you're taking away the security of a firewall. A *lot* of these problems we face are conceptual rather than technological. ~Seth
On 5/02/2009, at 2:35 PM, Seth Mattinen wrote:
Far too many people see NAT as synonymous with a firewall so they think if you take away their NAT you're taking away the security of a firewall.
A *lot* of these problems we face are conceptual rather than technological.
For more, refer to the 69,000 other NANOG posts on the topic. -- Nathan Ward
participants (10)
-
Anthony Roberts -
George William Herbert -
Jack Bates -
Leo Bicknell -
Mark Andrews -
Matthew Moyle-Croft -
Nathan Ward -
Owen DeLong -
Seth Mattinen -
TJ