Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
In message , "Ricky Beam" writes: > On Mon, 09 Feb 2009 21:11:50 -0500, TJ 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_andr...@isc.org
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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 5 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
RE: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
>> 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 LNG 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
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On Mon, 09 Feb 2009 21:11:50 -0500, TJ 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
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On Mon, Feb 9, 2009 at 9:47 PM, TJ 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
RE: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
>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).
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On Mon, Feb 9, 2009 at 6:16 PM, Ricky Beam wrote: > On Fri, 06 Feb 2009 09:39:01 -0500, Iljitsch van Beijnum > 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 5 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
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
In message <00cf01c98b24$efe42680$cfac73...@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_andr...@isc.org
RE: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
>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. 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). >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. 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).
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
Nathan Ward wrote: On 10/02/2009, at 11:35 AM, Scott Howard wrote: Go and ask those people who "feel statics are a given for IPv6" if they would prefer static or dynamic IPv4 addresses, and I suspect most/all of them will want the static there too. Now ask your average user the same question and see if you get the same answer. I imagine there will be a difference - in my experience few people understand the automatic renumbering that you can do with IPv6, so think that static addressing is the only way forward. With IPv4 this is not an issue, as they do not re-number internal interfaces when their external IPv4 address changes. I wonder how much this is all going to change as there's an inevitable shift from "my computer" being The Client, to "my computer" being one of many "servers" that my cell phone uses, and is generally tethered to. Or just the situation that you have more than one place of residence and there is a somewhat indeterminate concept of what "my computer" really is. This is somewhat reminiscent of the pop/imap days, but there's just so much more stuff these days and broadband is still way too slow to really have a completely viable network/server solution. Fast servers in the network are great, but there are is a fairly large set of things that it just doesn't handle well; manifestly given the still huge split between local and network storage. (what percentage of "stuff" is in the cloud? 1%?) To me, that says that more and more people are going to want to access their "home computer" as if it were a server... which in fact it really is in the case of an iPhone wanting to suck down the latest dross from iTunes. And server means non-client accessiblity however you accomplish that. Mike
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On Fri, 06 Feb 2009 09:39:01 -0500, Iljitsch van Beijnum 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
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On 10/02/2009, at 11:35 AM, Scott Howard wrote: Go and ask those people who "feel statics are a given for IPv6" if they would prefer static or dynamic IPv4 addresses, and I suspect most/ all of them will want the static there too. Now ask your average user the same question and see if you get the same answer. I imagine there will be a difference - in my experience few people understand the automatic renumbering that you can do with IPv6, so think that static addressing is the only way forward. With IPv4 this is not an issue, as they do not re-number internal interfaces when their external IPv4 address changes. -- Nathan Ward
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On Sat, Feb 7, 2009 at 5:56 PM, Matthew Moyle-Croft wrote: > 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 But is this a general requirement, or just one from the types of people that are likely to be early adopters for IPv6? Go and ask those people who "feel statics are a given for IPv6" if they would prefer static or dynamic IPv4 addresses, and I suspect most/all of them will want the static there too. Now ask your average user the same question and see if you get the same answer. I don't see static for IPv6 as any more (or less?) of an operational requirement than for IPv4. Certain users will definitely require static address, just as they do for IPv4, and IMHO these should be handled in exactly the same way - the exact mechanism for which will vary from ISP to ISP. Scott.
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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>
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
Bill Stewart wrote: 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 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: m...@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
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On Fri, Feb 6, 2009 at 7:12 PM, Matthew Moyle-Croft 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.
RE: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space(IPv6-MW)]
>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?
RE: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space(IPv6-MW)]
>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.
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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: m...@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
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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 K5SSSdice at every possible opportunity." --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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 Senied...@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
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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 Engineeryou'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins pgp0OhzlcjfGx.pgp Description: PGP signature
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space(IPv6-MW)]
On Fri, Feb 6, 2009 at 10:22 AM, Jamie Bowden 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
RE: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space(IPv6-MW)]
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:iljit...@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.0003% 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
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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.
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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.
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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.finchhttp://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD.
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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 Jakmap...@clubi.iep...@jakma.orgKey ID: 64A2FF6A Fortune: If you don't have a nasty obituary you probably didn't matter. -- Freeman Dyson
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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 p...@clubi.ie p...@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: m...@internode.com.auWeb: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999Fax: +61-8-8235-6909
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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 p...@clubi.ie p...@jakma.org Key ID: 64A2FF6A Fortune: If you don't have a nasty obituary you probably didn't matter. -- Freeman Dyson
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
"David W. Hankins" 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. > > http://en.wikipedia.org/wiki/SOCKS 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
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
In message <498bddac.7060...@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_andr...@isc.org
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
> 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?" randy
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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.1% 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_think_abundance_softly_does_it -- Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT.
RE: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
>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.
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
George William Herbert wrote: 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. 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
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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 Engineeryou'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins pgpnAIGUo35fd.pgp Description: PGP signature
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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 gherb...@retro.com
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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.)
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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...
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
In message , 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_andr...@isc.org
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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
RE: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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 rob...@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:hae...@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...
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On Thu, 05 Feb 2009 17:42:27 -0500, Iljitsch van Beijnum 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
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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 Engineeryou'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins pgpcpPI6Ekg8x.pgp Description: PGP signature
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...
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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 Engineeryou'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins pgp31Zvpm3F9i.pgp Description: PGP signature
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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 Engineeryou'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins pgpTe134pDUbT.pgp Description: PGP signature
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
In message , "Ricky Beam" writes: > On Thu, 05 Feb 2009 10:25:44 -0500, Iljitsch van Beijnum > 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_andr...@isc.org
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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.
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On Thu, 05 Feb 2009 17:18:15 -0500, Joe Abley 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
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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.cut...@consultant.com
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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.
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.0003% 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*.
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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.
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On Thu, 05 Feb 2009 10:25:44 -0500, Iljitsch van Beijnum 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
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW)
On Thursday 05 February 2009 04:31:28 Brandon Butterworth wrote: > > 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 . > > The thread seemed long and noisy enough already without everyone > doing a me too. > > We did it, to see if we could and because we have like > minded users wanting access. I know there are others. > > brandon Reading between the lines, nobody just wants to know THAT you've got it working. We want to know HOW you got it working. What protocols and policies were implemented on what hardware for what kind of user base? Stephen Kratzer Network Engineer CTI Networks, Inc.
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW)
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. pgpUw9F6bHgf7.pgp Description: PGP signature
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW)
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
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW)
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.
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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.
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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.
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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
RE: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW)
>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 ...
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW)
Scott Howard wrote: > > 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... No, it's because neither need to do it. If they did the apparent catch-22 would be fixed Matthew Moyle-Croft wrote: > As I asked before - has ANYONE done this before? ie. fully > dualstacked to customers? Or is it still theory? We have ADSL users with v4 and v6, they mostly use low end Ciscos, 837 and such (cheap on ebay so for the tech user base it's not too hard) Cheap retail CPE adding v6 by default would help. James W. Laferriere wrote: > Hello Matthew , See way below ... It's not so far if you don't quote the entire message > 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 . The thread seemed long and noisy enough already without everyone doing a me too. We did it, to see if we could and because we have like minded users wanting access. I know there are others. brandon
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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 Abrahamssonemail: swm...@swm.pp.se
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW)
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 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 >wrote: On Wed, Feb 4, 2009 at 5:20 PM, Matthew Moyle-Croft >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 | SystemTechniques | Give me VMS | | Network&System Engineer | 2133McCullam Ave | Give me Linux | | bab...@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: m...@internode.com.auWeb: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999Fax: +61-8-8235-6909 !DSPAM:22,498a6b69305768916813158!
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW)
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 >wrote: On Wed, Feb 4, 2009 at 5:20 PM, Matthew Moyle-Croft >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 | SystemTechniques | Give me VMS | | Network&System Engineer | 2133McCullam Ave | Give me Linux | | bab...@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: m...@internode.com.auWeb: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999Fax: +61-8-8235-6909 -- Matthew Moyle-Croft Internode/Agile Peering and Core Networks Level 5, 162 Grenfell Street, Adelaide, SA 5000 Australia Email: m...@internode.com.auWeb: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999Fax: +61-8-8235-6909
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW)
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 >wrote: On Wed, Feb 4, 2009 at 5:20 PM, Matthew Moyle-Croft >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 | SystemTechniques | Give me VMS | | Network&System Engineer | 2133McCullam Ave | Give me Linux | | bab...@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: m...@internode.com.auWeb: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999Fax: +61-8-8235-6909
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW)
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 wrote: On Wed, Feb 4, 2009 at 5:20 PM, Matthew Moyle-Croft 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 | SystemTechniques | Give me VMS | | Network&System Engineer | 2133McCullam Ave | Give me Linux | | bab...@baby-dragons.com | Fairbanks, AK. 99701 | only on AXP | +--+
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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: m...@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
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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. 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. 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 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: m...@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
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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 - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
pgpLTGKuEROCj.pgp
Description: PGP signature
RE: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
>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.
RE: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
>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
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW)
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
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW)
Scott Howard wrote: On Wed, Feb 4, 2009 at 4:16 PM, Patrick W. Gilmore wrote: On Wed, Feb 4, 2009 at 5:20 PM, Matthew Moyle-Croft 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: m...@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
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW)
In message , Scott Howard writes: > On Wed, Feb 4, 2009 at 4:16 PM, 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. > > > 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 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_andr...@isc.org
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
-- m...@internode.com.au wrote: From: Matthew Moyle-Croft 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. --- Please state on list. Many of would like to learn from your experiences. scott
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
In message <498a40c1.8060...@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_andr...@isc.org
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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: m...@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
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
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
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW)
On Wed, Feb 4, 2009 at 4:16 PM, 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. 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 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.
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
Mark Andrews wrote: > In message <498a3ca5.6060...@internode.com.au>, Matthew Moyle-Croft writes: >> Anthony Roberts wrote: >>> On Thu, 05 Feb 2009 11:08:44 +1030, Matthew Moyle-Croft >>> 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
