Re: ISP customer assignments
On Tue, Oct 20, 2009 at 10:15:39PM -0400, Roland Dobbins wrote: On Oct 20, 2009, at 8:41 PM, Karl Auer wrote: In practice, changing stuff, especially globally, is not as simple as that. From http://tools.ietf.org/html/rfc4192: 'Some took it on themselves to convince the authors that the concept of network renumbering as a normal or frequent procedure is daft.' We tried Fred's procedure some 4 years ago within 6NET: http://www.6net.org/publications/deliverables/D3.6.2.pdf The 'prefix schizo' actually worked out quite well. The routing changes and multi-refix links generally behaved as expected. Address selection did its thing. The basics worked as advertised. The complexity is of course not in the routing and hosts, it's as pointed out in the firewalls and similar devices (yours and more importantly other people's) for which new capabilities of IPv6 can't help. We captured some of these thoughts at the time in http://tools.ietf.org/html/draft-chown-v6ops-renumber-thinkabout-05 and since then Brian Carpenter has produced a much more up to date and rounded set of thoughts in http://tools.ietf.org/html/draft-carpenter-renum-needs-work-03 We're far from a magic button press. In smaller networks RFC4192 is workable, but the larger and more complex the network/site, there's still so many open issues that it's completely understandable the people will want PI. -- Tim
Re: ISP customer assignments
On Tue, 20 Oct 2009 19:38:58 -0400, Bill Stewart nonobvi...@gmail.com wrote: ... If you've got a VPN tunnel device, too often the remote end will want to contact you at some numerical IPv4 address and isn't smart enough to query DNS to get it. As I was told by Cisco, that's a security feature. Fixed VPN endpoints are supposed to be *fixed* endpoints. Yes, it is a pain when an address changes, for whatever reason. But relying on DNS to eventually get the endpoint(s) right is an even bigger mess... how often is the name-IP updated? how often do the various DNS servers revalidate those records? how often do the VPN devices revalidate the names? what happens when the dns changes while the vpn is still up? I'll stick with entering IP addresses. --Ricky
Re: ISP customer assignments
In message op.u156b0mztfh...@rbeam.xactional.com, Ricky Beam writes: On Tue, 20 Oct 2009 19:38:58 -0400, Bill Stewart nonobvi...@gmail.com wrote: ... If you've got a VPN tunnel device, too often the remote end will want to contact you at some numerical IPv4 address and isn't smart enough to query DNS to get it. As I was told by Cisco, that's a security feature. Fixed VPN endpoints are supposed to be *fixed* endpoints. Yes, it is a pain when an address changes, for whatever reason. But relying on DNS to eventually get the endpoint(s) right is an even bigger mess... how often is the name-IP updated? It should be automatically updated by the end point. We do have the technology to do that. how often do the various DNS servers revalidate those records? If you are talking about caching servers then they will honour the TTL in the records. how often do the VPN devices revalidate the names? At startup. A well designed VPN protocol will support end point address mobility. what happens when the dns changes while the vpn is still up? This should be transparent to everything other than the vpn end points. I'll stick with entering IP addresses. --Ricky -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: ISP customer assignments
On Mon, Oct 19, 2009 at 7:07 PM, Nathan Ward na...@daork.net wrote: On 20/10/2009, at 3:02 PM, Bill Stewart wrote: plus want the ability to take their address space with them when they change ISPs (because there are too many devices and applications that insist on having hard-coded IP addresses instead of using DNS, and because DNS tends to get cached more often than you'd sometimes like. That's why we have Unique Local Addresses. This is the opposite problem - ULAs are for internal devices, and what businesses often want is globally routable non-provider-owned public addresses. If you've got a VPN tunnel device, too often the remote end will want to contact you at some numerical IPv4 address and isn't smart enough to query DNS to get it. And even though most enterprises these days only use registered addresses outside the firewall and not inside the firewall, it's still a pain to have to renumber everything and wait for everybody's DNS caches to expire, so if you're using Provider-independent IP addresses, it's much easier to tell your ISP Sorry, ISP A, I've got a better price from ISP B and I'll move all my stuff if you don't beat their price. (Of course, customers like that are often telling ISP B You'll have to be X% cheaper/faster/somethinger than ISP A or I'll just stay where I am and telling ISP C My main choices are ISP A and ISP B but I'd take a lowball quote very seriously...) -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: ISP customer assignments
In message 18a5e7cb0910201638j7a24a10dwb8440a42f8f9c...@mail.gmail.com, Bill Stewart writes: On Mon, Oct 19, 2009 at 7:07 PM, Nathan Ward na...@daork.net wrote: On 20/10/2009, at 3:02 PM, Bill Stewart wrote: plus want the ability to take their address space with them when they change ISPs (because there are too many devices and applications that insist on having hard-coded IP addresses instead of using DNS, and because DNS tends to get cached more often than you'd sometimes like. That's why we have Unique Local Addresses. This is the opposite problem - ULAs are for internal devices, and what businesses often want is globally routable non-provider-owned public addresses. If you've got a VPN tunnel device, too often the remote end will want to contact you at some numerical IPv4 address and isn't smart enough to query DNS to get it. Which just means we should be fixing the VPN box. And even though most enterprises these days only use registered addresses outside the firewall and not inside the firewall, it's still a pain to have to renumber everything and wait for everybody's DNS caches to expire, so if you're using Provider-independent IP addresses, it's much easier to tell your ISP Sorry, ISP A, I've got a better price from ISP B and I'll move all my stuff if you don't beat their price. (Of course, customers like that are often telling ISP B You'll have to be X% cheaper/faster/somethinger than ISP A or I'll just stay where I am and telling ISP C My main choices are ISP A and ISP B but I'd take a lowball quote very seriously...) Renumbering in IPv6 is not the same as renumbering in IPv4. IPv6 is designed to support multiple prefixes on the one interface. There is actually enough address space to support doing this and allow renumber events to take weeks or months if needed. There is no need to say at XX:XX on DD/MM/ we will be switching prefixes. One can be much smarter about how you do it. You can just introduce the new prefix. Add second address to the DNS. Do your manual fixes. Remove the old addresses from the DNS. Stop using the old prefix when you are satisfied that there is no traffic over them. -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: ISP customer assignments
There is no need to say at XX:XX on DD/MM/ we will be switching prefixes. One can be much smarter about how you do it. You can just introduce the new prefix. Add second address to the DNS. Do your manual fixes. Remove the old addresses from the DNS. Stop using the old prefix when you are satisfied that there is no traffic over them. True in principle. In practice, changing stuff, especially globally, is not as simple as that. Many (most?) enterprises still have pretty primitive DNS/DHCP management. While there are good management systems out there, many of the largest are custom made for the enterprise concerned, and are not yet up to speed with IPv6. The practical experience is not yet there to drive the development of the right features - especially ones as rare as a complete renumbering. DHCPv6 server software is still pretty early days, too. The addressing on infrastructure kit like routers and switches, firewalls and IDS boxes and so on is also typically hard coded and difficult to change, as are the addresses used in ACLs and firewall rules. Renumbering means: - adding a new record to the DNS for every existing record, but using a different prefix (plus any other DNS changes needed - like giving the servers themselves addresses in the new prefix, and making sure they reply from the right address...) Reverse lookups may be an issue during the changeover, too. - updating DHCP configurations to issue addresses from the new prefixes, automatically divided along the same numbering plan - setting up reserved DHCP addresses with the same host parts as the old reserved addresses but using the new prefix etc - adding new addresses to every location where an address is hardcoded - such as in router and switch configurations - updating ACLs to account for the new addresses (without discarding the old rules yet) - updating firewall rules and what-have-you to account for the new prefix, without discarding the old ones yet - waiting the weeks or months until the old prefix may be safely discarded. During this time you have a prefix-schizo network. - updating firewall rules and what-have-you to remove the old prefix - updating ACLs to remove the old addresses - removing old addresses from every location where an address is hardcoded - such as in router and switch configurations - removing now-unused DHCP reservations - removing now-unwanted DHCP ranges - removing all records that reference the old prefix ... and this is by no means an exhaustive list. Many higher-level services will also need updating (twice) - your web server configurations, for example. And it gets more complicated if your prefix changes length as well. And what if the network was not set up with future renumbering in mind? DHCP servers issuing eternal leases, things like that. So once again the theory is good, but reality intrudes. Renumbering, even with the undeniably much better features of IPv6, is still going to be a royal pain. Of course, IPv6 may drive improvements in all these areas over time, but they're not there yet. Wouldn't it be cool to have a renumber router command that just took an old prefix, a new prefix and a number of seconds and did all the work? Regards, K. PS: If anyone knows of an IPAM that can do all the above, or even just some of the above, please let me know! -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF signature.asc Description: This is a digitally signed message part
Re: ISP customer assignments
In message 1256085698.30246.109.ca...@karl, Karl Auer writes: There is no need to say at XX:XX on DD/MM/ we will be switching prefixes. One can be much smarter about how you do it. =20 You can just introduce the new prefix. Add second address to the DNS. Do your manual fixes. Remove the old addresses from the DNS. Stop using the old prefix when you are satisfied that there is no traffic over them. True in principle. In practice, changing stuff, especially globally, is not as simple as that. Many (most?) enterprises still have pretty primitive DNS/DHCP management. While there are good management systems out there, many of the largest are custom made for the enterprise concerned, and are not yet up to speed with IPv6. The practical experience is not yet there to drive the development of the right features - especially ones as rare as a complete renumbering. DHCPv6 server software is still pretty early days, too. The addressing on infrastructure kit like routers and switches, firewalls and IDS boxes and so on is also typically hard coded and difficult to change, as are the addresses used in ACLs and firewall rules. Renumbering means: - adding a new record to the DNS for every existing record, but using a different prefix (plus any other DNS changes needed - like giving the servers themselves addresses in the new prefix, and making sure they reply from the right address...) Reverse lookups may be an issue during the changeover, too. - updating DHCP configurations to issue addresses from the new prefixes, automatically divided along the same numbering plan - setting up reserved DHCP addresses with the same host parts as the old reserved addresses but using the new prefix etc - adding new addresses to every location where an address is hardcoded - such as in router and switch configurations - updating ACLs to account for the new addresses (without discarding the old rules yet) - updating firewall rules and what-have-you to account for the new prefix, without discarding the old ones yet - waiting the weeks or months until the old prefix may be safely discarded. During this time you have a prefix-schizo network. - updating firewall rules and what-have-you to remove the old prefix - updating ACLs to remove the old addresses - removing old addresses from every location where an address is hardcoded - such as in router and switch configurations - removing now-unused DHCP reservations - removing now-unwanted DHCP ranges - removing all records that reference the old prefix ... and this is by no means an exhaustive list. Many higher-level services will also need updating (twice) - your web server configurations, for example. And it gets more complicated if your prefix changes length as well. And what if the network was not set up with future renumbering in mind? DHCP servers issuing eternal leases, things like that. So once again the theory is good, but reality intrudes. Renumbering, even with the undeniably much better features of IPv6, is still going to be a royal pain. Of course, IPv6 may drive improvements in all these areas over time, but they're not there yet. Wouldn't it be cool to have a renumber router command that just took an old prefix, a new prefix and a number of seconds and did all the work? Well request it from you favorite router vendors. Router/vpn/firewall vendors should be forced to renumber annually. That way they would have some incentive to make their products usable when a renumber event occurs. The same applies to other vendors. Regards, K. PS: If anyone knows of an IPAM that can do all the above, or even just some of the above, please let me know! --=20 ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF --=-lq/A/spfwZ9P7pLx73k/ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkreWLgACgkQSkRqA/Q6fe//UACfcPMTlaufxR4sk8pfJ9d7Uk/W rW4AmgNnotHOzM4DnvcT90ow+0kDxMVF =aZzD -END PGP SIGNATURE- --=-lq/A/spfwZ9P7pLx73k/-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: ISP customer assignments
On Oct 20, 2009, at 8:41 PM, Karl Auer wrote: In practice, changing stuff, especially globally, is not as simple as that. From http://tools.ietf.org/html/rfc4192: 'Some took it on themselves to convince the authors that the concept of network renumbering as a normal or frequent procedure is daft.' --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Sorry, sometimes I mistake your existential crises for technical insights. -- xkcd #625
Re: ISP customer assignments
In message 1069dfd4-87a3-4e38-aebc-43c05c16d...@arbor.net, Roland Dobbins wri tes: On Oct 20, 2009, at 8:41 PM, Karl Auer wrote: In practice, changing stuff, especially globally, is not as simple as that. From http://tools.ietf.org/html/rfc4192: 'Some took it on themselves to convince the authors that the concept of network renumbering as a normal or frequent procedure is daft.' There is a difference between renumbering every minute and renumber when required to optimise something else. We shouldn't be afraid to renumber. It should be something all vendors support. It should be as automated as possible. If there is a manual step you should be asking yourself does this need to be done by hand. Remember there are lots of machines that renumber themselves several times a day as they move between work and home. All machines should be in a position to renumber themselves as easily as we renumber a laptop. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: ISP customer assignments
On Oct 20, 2009, at 10:29 PM, Mark Andrews wrote: Remember there are lots of machines that renumber themselves several times a day as they move between work and home The problem isn't largely with the endpoints - it's with all the other devices/policies/etc. which overload the EID with inappropriate significance which tend to cause most of the problems. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Sorry, sometimes I mistake your existential crises for technical insights. -- xkcd #625
Re: ISP customer assignments
If you've got an addressing system with enough bits that you don't have to start stealing them, it makes sense to pick some boundary length between our-problem : their-problem 128 bits is long enough, and changing protocols is nasty enough, that it should let you Never Have To Do It Again. Originally with IPv6, the boundary was a nice round 64 bits, with the ISP on the network side and MAC48-based autoaddressing on the user side, with the user side looking suspiciously similar to Novell Netware and giving ~64K subnets, and this was back before DHCP had taken over the world and it was expected that all kinds of weird little toasters would be using IPv6. But some relatively sensible people proposed using the (ugly) EUI-64 64-bit MAC, because they Never Wanted To Have To Do This Again Either. And unfortunately, because it's a good enough idea to be worth accepting, it pushes the network boundary somewhat to the left, because it's pretty obvious that an average household may have multiple devices that want to autoconfigure themselves, so you probably will end up needing multiple subnets. And unfortunately, there's no obviously correct boundary, and no particular reason for all ISPs to use the same boundary, so there are endless arguments about it on NANOG and elsewhere. In general, /48's big enough for most large complex businesses (except ISPs), and /60's more than big enough for a household and for many small businesses, but we've got enough bits that it's worth using octet-aligned addresses, so /56 is the magic number for them, except at ISPs that simply don't want to bother giving out anything except /48s. There may be special cases for assigning /64s to end users, such as IPv6-equipped cell phones, but that's a matter for specialized carriers to provide, or for internal network managers at enterprises. And if you're big enough to get Provider Independent Address Space and an AS#, you're big enough to have a /48 of your own. Now, IPv6 was supposed to allow the development of other indistinguishable-from-magically advanced technology, such as getting rid of the growth of routing tables by convincing everybody to be happy with hierarchically assigned provider-aligned address space, and unfortunately that hasn't matched the needs of businesses, which need multihoming for reliability (so they'll be non-provider-aligned for at least n-1 of their ISPs), plus want the ability to take their address space with them when they change ISPs (because there are too many devices and applications that insist on having hard-coded IP addresses instead of using DNS, and because DNS tends to get cached more often than you'd sometimes like. So that problem shows no sign of going away (in spite of shim6..)
Re: ISP customer assignments
On 20/10/2009, at 3:02 PM, Bill Stewart wrote: plus want the ability to take their address space with them when they change ISPs (because there are too many devices and applications that insist on having hard-coded IP addresses instead of using DNS, and because DNS tends to get cached more often than you'd sometimes like. That's why we have Unique Local Addresses. -- Nathan Ward
Re: ISP customer assignments
On 20/10/2009, at 3:10 PM, bmann...@vacation.karoshi.com wrote: On Tue, Oct 20, 2009 at 03:07:39PM +1300, Nathan Ward wrote: On 20/10/2009, at 3:02 PM, Bill Stewart wrote: plus want the ability to take their address space with them when they change ISPs (because there are too many devices and applications that insist on having hard-coded IP addresses instead of using DNS, and because DNS tends to get cached more often than you'd sometimes like. That's why we have Unique Local Addresses. but Nathan, they are only statistically unique. Sure, but I don't think that changes my point. Also if you want to increase your chances of uniqueness (which are already pretty good if you're not using subnet 0 or 1 or whatever) you can jump on to somewhere on the sixxs site and announce that you're using a specific ULA prefix. -- Nathan Ward
Re: ISP customer assignments
This is a bit annoying though, yeah. But, I'm not sure I can think of a good solution that doesn't involve us changing the routing system so that we can handle a huge amount of intentional de-aggregates or something. Within the RIPE region we're currently discussing a document on IPv6 route aggregation that acknowledges there are cases where it may be necessary to break up a /32 into a limited number of smaller blocks. Following discussion at the meeting last week I need to revise it, but the previous draft is here: http://www.ripe.net/ripe/maillists/archives/routing-wg/2009/msg00120.html Cheers, Rob
Re: ISP customer assignments
* Chris Adams This brings up something else I'm trying to figure out. We're not a huge ISP; I've got our /32 but I don't see us using more. We have two main POPs, each with Internet links, plus a link between the two. Our IPv4 allocations are larger than the minimum, so I split our IPv4 space between the two POPs and avertise a smaller block out of the smaller of the two POPs. This has worked okay and handles the POP-to-POP link going down; when that happens, our POP-to-POP traffic (not a large precentage of our traffic) goes across our Internet connections, but Internet traffic for each POP goes to directly to the POP. With IPv6, we've got our single /32. From what I understand, if I try to advertise a /33 from the smaller POP, many (most?) will drop it (if my upstreams even take it). If I advertise the /32 from both routers, when that link goes down, my IPv6 traffic will be pretty much hosed. What you can do is to set up a tunnel between the sites (can be encrypted if necessary) through your upstream(s), and include it in your IGP - making sure that it has a higher cost/metric than the dedicated circuit. If then the dedicated circuit goes down, the traffic between the PoPs is redirected through the tunnel, and no connectivity is lost. You might need to upgrade the capacity of the dedicated circuit though, since there's no avoiding that some inbound packets will be delivered to the wrong PoP. Also you should make sure that the ports to your upstreams have enough available burst capacity (and preferably a roomy percentile-based charging scheme so that a bit of downtime on the dedicated circuit won't cost you anything). If you're single-homing to the the same upstream AS at both sites, another solution is to announce the aggregate /32 from both PoPs and at the same time a more specific route from each of them tagged with the no-export community (assuming your upstream will accept the deaggregated route in both locations). Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27
Re: ISP customer assignments
The big problem here is that CIDR is tough to teach, even to engineering students. This seems bizarre and counterintuitive, but its true. I know this because I've done it. Its really easy to teach classful addressing, on the other hand. Other problems include the issue that many of the folks teaching have never had to use CIDR in real life, textbook age, and, in some cases, lack of mathematical preparation and inclination on the part of students. Scarier: I was teaching graduate students. - Dan On Oct 13, 2009, at 7:53 AM, Joe Abley wrote: On 2009-10-13, at 07:39, Scott Morris wrote: No idea, I haven't looked at that stuff in a while. But I would assume so, as it's easier to build a foundation than jumping straight to something difficult? I've found RIP to be a reasonable way to teach the concept of a routing protocol, since the protocol is very simple and you can always close with don't ever use this. But teaching classful routing and addressing is just moronic. It's a foundation that nothing is built on any more, and makes no sense to teach outside of a history class. Or did you learn calculus in grade school? Just askin' ;) Yes, since you asked, but your presumption is faulty. Joe
RE: ISP customer assignments
I actually think that CIDR is easier to understand than classful addressing. Do the subject completely in binary. It makes complete sense then. - Brian BTW: If the grad students don't get it, fail them! I don't want an engineer who can't grasp basic binary math. -Original Message- From: Daniel Golding [mailto:dgold...@t1r.com] Sent: Friday, October 16, 2009 3:51 PM To: Joe Abley Cc: NANOG Subject: Re: ISP customer assignments The big problem here is that CIDR is tough to teach, even to engineering students. This seems bizarre and counterintuitive, but its true. I know this because I've done it. Its really easy to teach classful addressing, on the other hand. Other problems include the issue that many of the folks teaching have never had to use CIDR in real life, textbook age, and, in some cases, lack of mathematical preparation and inclination on the part of students. Scarier: I was teaching graduate students. - Dan
Re: ISP customer assignments
I've got to agree with Brian, especially in an ISP environment, why would anyone hire or keep someone who couldn't grasp the concept of CIDR? You certainly wouldn't want to have them maintaining a core router with lots of v4 routes, since router-router links are almost always numbered in subnets as small as logic dictates. On 10/16/2009 01:58 PM, Brian Johnson wrote: I actually think that CIDR is easier to understand than classful addressing. Do the subject completely in binary. It makes complete sense then. - Brian BTW: If the grad students don't get it, fail them! I don't want an engineer who can't grasp basic binary math. -Original Message- From: Daniel Golding [mailto:dgold...@t1r.com] Sent: Friday, October 16, 2009 3:51 PM To: Joe Abley Cc: NANOG Subject: Re: ISP customer assignments The big problem here is that CIDR is tough to teach, even to engineering students. This seems bizarre and counterintuitive, but its true. I know this because I've done it. Its really easy to teach classful addressing, on the other hand. Other problems include the issue that many of the folks teaching have never had to use CIDR in real life, textbook age, and, in some cases, lack of mathematical preparation and inclination on the part of students. Scarier: I was teaching graduate students. - Dan -- Walter Keen Network Technician Rainier Connect (o) 360-832-4024 (c) 253-302-0194
Re: ISP customer assignments - and CIDR
On Oct 16, 2009, at 5:19 PM, Owen DeLong wrote: I've taught both. If you try to teach it in Decimal, Hex, or Octal, you're right, it's hard to teach CIDR and easy to teach classful. It really does not matter the representation as long as you divide your Address Pie with a Binary Knife. Once you understand that -- 1/2, 1/2 of 1/2, 1/2 of 1/2 of 1/2, ... -- then you should understand CIDR. Then, as Owen suggests, deal with the representation. Works for IPv4, IPv6, and, probably, IPv8. ;) Warning, strong opinion follows: One should never have to mention Classful addressing except to note that it is archaic, anachronistic, and used only by those who remain ignorant by preference. James R. Cutler james.cut...@consultant.com
Re: ISP customer assignments
I can't offer any knowledgeable advice about PPPoA/E. We have never used it ourselves. On 14/10/09 22:16 -0500, Frank Bulk wrote: So you're saying moving away from PPPoA/E and just going bridged? Frank -Original Message- From: Dan White [mailto:dwh...@olp.net] Ask Pannaway if they can bridge traffic (either ATM PVC, or Ethernet QinQ/VLAN per subscriber) up to a broadband aggregator, like a Redback or Cisco. -- Dan White
Re: ISP customer assignments
Of course, with IPv4, you never assigned a large enough block to begin with that would anticipate all growth, so routing additional blocks was a lot easier than changing blocks, cleaner than secondary IPs multiplying like crazy, etc., etc. None of that would be an issue with a single /64. You've hit on the key difference of IPv6. With IPv6 you should design your network so that it can grow for a long time without increasing the address block sizes anywhere. A /64 will work for even the biggest subnets. A /48 will do for for very, very big sites. And only the largest ISPs will outgrow a /32 allocation. If you assign a /48 to a data center site, then when you subnet it, try to maintain that growth ability if you can. Don't skimp on address block sizes unless you are backed into a corner for technical or business reasons. --Michael Dillon
Re: ISP customer assignments
Once upon a time, Michael Dillon wavetos...@googlemail.com said: And only the largest ISPs will outgrow a /32 allocation. This brings up something else I'm trying to figure out. We're not a huge ISP; I've got our /32 but I don't see us using more. We have two main POPs, each with Internet links, plus a link between the two. Our IPv4 allocations are larger than the minimum, so I split our IPv4 space between the two POPs and avertise a smaller block out of the smaller of the two POPs. This has worked okay and handles the POP-to-POP link going down; when that happens, our POP-to-POP traffic (not a large precentage of our traffic) goes across our Internet connections, but Internet traffic for each POP goes to directly to the POP. With IPv6, we've got our single /32. From what I understand, if I try to advertise a /33 from the smaller POP, many (most?) will drop it (if my upstreams even take it). If I advertise the /32 from both routers, when that link goes down, my IPv6 traffic will be pretty much hosed. Is there any good solution to this? I don't expect us to fill the /32 to justify expanding it (although I do see ARIN appears to have left space for up to a /29; I guess that's their sparse allocation policy?). I guess this is traffic engineering, although I'm not deaggregating to try to control how much goes where, just to ensure connectivity in the face of failures. This link has been pretty reliable lately (since the telco re-engineered it), but it was flakey as hell a while back (when it went through 7 companies to go between cities 90 miles apart). -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: ISP customer assignments
On 16/10/2009, at 1:17 PM, Chris Adams wrote: Is there any good solution to this? I don't expect us to fill the /32 to justify expanding it (although I do see ARIN appears to have left space for up to a /29; I guess that's their sparse allocation policy?). Your justification is that you have two sites without a guaranteed link between them. This is a bit annoying though, yeah. But, I'm not sure I can think of a good solution that doesn't involve us changing the routing system so that we can handle a huge amount of intentional de-aggregates or something. -- Nathan Ward
Re: ISP customer assignments
On Thu, Oct 15, 2009 at 8:17 PM, Chris Adams cmad...@hiwaay.net wrote: With IPv6, we've got our single /32. From what I understand, if I try to advertise a /33 from the smaller POP, many (most?) will drop it (if my upstreams even take it). If I advertise the /32 from both routers, when that link goes down, my IPv6 traffic will be pretty much hosed. Is there any good solution to this? Chris, Here's what I do with my IPv4 /24: I advertise it at higher priority at the larger POP and a slightly lower priority at the smaller POP. Then I got a small block of addresses from each upstream at each POP (from their still-aggregated blocks) to anchor a set of VPNs between the two. Something has to go disastrously wrong for me to suffer any worse effects than the occasional inefficient routing. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: ISP customer assignments
Nathan Ward wrote: On 16/10/2009, at 1:17 PM, Chris Adams wrote: Is there any good solution to this? I don't expect us to fill the /32 to justify expanding it (although I do see ARIN appears to have left space for up to a /29; I guess that's their sparse allocation policy?). Your justification is that you have two sites without a guaranteed link between them. This is a bit annoying though, yeah. But, I'm not sure I can think of a good solution that doesn't involve us changing the routing system so that we can handle a huge amount of intentional de-aggregates or something. -- Nathan Ward Actually, as of right now that's not justification. The Multiple Discrete Networks policy that's up for a vote in Dearborn will allow for this, but right now there's no IPv6 equivalent of that policy. -Dave
Re: ISP customer assignments
Ok, I've decided to do this a different way to my usual ranting. Instead of explaining the options over and over and hoping people can make sense of the complexities of it, become experts, and make good informed decisions, I've made a flow chart. Feel free to ask about details and I can get in to the ranting part, this is really a place to start. Right now it assumes people only provide DSL or other dynamic sort of services. It also assumes DS-Lite people are insane, so probably need better language there. Also the first question is not necessarily about who you are, but who is driving the IPv6 'build' - which is why native, 6rd and ds-lite are not appropriate for the customer-driven side. I hope that makes sense. No talk about ISATAP and stuff for inside the customer network either. And before you ask no ISATAP is not appropriate for ISPs, doesn't work through NAT. Anyway: - 6RD is used by free.fr. Not widely implemented by anyone yet. - DS-Lite is something some guys at Comcast and others are talking about. Not widely implemented by anyone yet. - The rest you can figure out from wikipedia and stuff. Please email me with any corrections, complaints, or threats if you're a DS-Lite fan. I'll always keep old versions in this directory, and the latest version will always have this filename, so please link to it instead of copying it, etc. etc.: http://www.braintrust.co.nz/resources/ipv6_flow_chart/ipv6_flow_chart-current.pdf On 13/10/2009, at 11:26 PM, Adrian Chadd wrote: Nathan Ward, please stand up. Adrian On Tue, Oct 13, 2009, TJ wrote: -Original Message- From: Justin To go along with Dan's query from above, what are the preferred methods that other SPs are using to deploy IPv6 with non-IPv6-capable edge hardware? We too have a very limited number of dialup customers and will never sink another dollar in the product. Unfortunately I also have brand-new ADSL2+ hardware that doesn't support IPv6 and according to the vendors (Pannaway) never will. We also have CMTSs that don't support IPv6, even though they too are brand-new. Those CMTSs top out at DOCSIS 2.0 and the vendor decided not to allow IPv6 to the CPEs regardless of the underlying CM's IPv6 support or lack thereof (like Cisco allowed for example). Are providers implementing tunneling solutions? Pros/cons of the various solutions? My first (potentially ignorant) response would be to get your acquisitions people aligned with your business, and by that I mean they should be making a concerted effort to only buy IPv6 capable gear, especially when IPv6 is coming to you within that gears lifecycle. I guess your customers will need to tunnel, as long as you give them a public IP they have 6to4 (and possibly Teredo, tunnel broker) - but native is better. -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA - !DSPAM:22,4ad455ce140151847938845!
Re: ISP customer assignments
In message eecc7b21-7390-446b-b54f-48d92ab88...@daork.net, Nathan Ward writes: Ok, I've decided to do this a different way to my usual ranting. Instead of explaining the options over and over and hoping people can make sense of the complexities of it, become experts, and make good informed decisions, I've made a flow chart. Feel free to ask about details and I can get in to the ranting part, this is really a place to start. Right now it assumes people only provide DSL or other dynamic sort of services. It also assumes DS-Lite people are insane, so probably need better language there. DS-Lite is there for when the ISP runs out of IPv4 addresses to hand one to each customer. Many customers don't need a unique IPv4 address, these are the ones you switch to DS-Lite. Those that do require a unique IPv4 you leave on full dual stack for as long as you can. You forgot the tunnel brokers. Also the first question is not necessarily about who you are, but who is driving the IPv6 'build' - which is why native, 6rd and ds-lite are not appropriate for the customer-driven side. I hope that makes sense. No talk about ISATAP and stuff for inside the customer network either. And before you ask no ISATAP is not appropriate for ISPs, doesn't work through NAT. Anyway: - 6RD is used by free.fr. Not widely implemented by anyone yet. - DS-Lite is something some guys at Comcast and others are talking about. Not widely implemented by anyone yet. - The rest you can figure out from wikipedia and stuff. Please email me with any corrections, complaints, or threats if you're a DS-Lite fan. I'll always keep old versions in this directory, and the latest version will always have this filename, so please link to it instead of copying it, etc. etc.: http://www.braintrust.co.nz/resources/ipv6_flow_chart/ipv6_flow_chart-current.pdf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
RE: ISP customer assignments
In a message written on Tue, Oct 13, 2009 at 08:14:40PM -0500, Chris Adams wrote: .. What about web-hosting type servers? Right now, I've got a group of servers in a common IPv4 subnet (maybe a /26), with a /24 or two routed to each server for hosted sites. What is the IPv6 equivalent? I can see a /64 for the common subnet, but what to route for aliased IPs for web hosts? It is kind of academic right now, since our hosting control panel software doesn't handle IPv6, but I certainly won't be putting 2^64 sites on a single server. Use a /112 here again as well? Use a /64 per server because I can? I'd be interested in any suggestions on this part as well. We're a Hosting provider and basicly we have (for now) 3 different product-groups we want to launch IPv6 on : 1 - Shared Hosting These servers (Linux), are all in 1 vlan. Each server has 1 IPv4 address from the subnet that's configured on the vlan. Then we have an IPv4 /24 routed to each of the servers (each server has 1 /24 to host sites on). Here I'd assign a single /64 and use static addressing. 2 - Premium Managed Unmanaged Hosting (Co-location). Each customer has one (or more) dedicated subnets and vlans. Here I'd assign a /64 per vlan. I'd do static addressing for Managed, but probably provide RA (EUI-64) for Unmanaged. 3 - Managed and Umanaged Hosting (Co-location). These servers are in 'shared' subnets, ranging from /23 to /26, and each customer get's assigned at least 1 IP from this subnet and more if they can justify. For customers needing 'large' subnets, we'd route a different subnet to their server of choice. Here, I'm not sure what to do... You should at least assign a /64 per customer, but how would one do that when they are in shared subnets/vlans... ? If for every server I'd need to assign a /64 secondary to our vlan interfaces, I'd trip the maximums (Nortel Passport 8600 used for these customers has quite some limitations on IPv6). It would be nice though, cause once IPv4 is no longer used (...) we could move customers to another/dedicated vlan. We've also fiddled with the idea of assigning one /48 to each of these vlans, and let each 'server' use a /64 out of it. This still seems a bit weird though... Also, since we do IP based billing here, we'd never know if one has 'hijacked' some IP space. Yes, we'd know for un-assigned addresses (not assigned but has traffic - alert), but I don't expect a customer to use all addresses out of 'their' /64, so the not used addresses could be easily be abused. For IPv4, all addresses are usually really used and the customer who's IP's are hijacked, would almost definitely hang on the phone in no-time. Some advice would be very appreciated. Best regards, Wouter de Jong WideXS
Re: ISP customer assignments
On 14/10/2009, at 7:23 PM, Mark Andrews wrote: DS-Lite is there for when the ISP runs out of IPv4 addresses to hand one to each customer. Many customers don't need a unique IPv4 address, these are the ones you switch to DS-Lite. Those that do require a unique IPv4 you leave on full dual stack for as long as you can. The authors of DS-lite say it's because running a dual stack network is hard. You clearly don't share that view , so in your view what's wrong with dual stack with IPv4for everyone then, whether they need a unique address or not? DS-lite requires CGN, so does dual stack without enough IPv4 addresses. This is probably the wrong forum for a DS-lite debate. I'm sure people have a use for it, they actually might have gear that can only do IPv4 OR IPv6 but not both or something. My problem with it is that it's being seen as a solution for a whole lot of people, when in reality it's a solution for a small number of people. Thanks for the point about the tunnel brokers though, I missed that, I'll update this tomorrow with any suggestions I get before then. -- Nathan Ward
Re: ISP customer assignments
In message e752070a-9081-4b36-8fb9-f60e0e420...@daork.net, Nathan Ward writes : On 14/10/2009, at 7:23 PM, Mark Andrews wrote: DS-Lite is there for when the ISP runs out of IPv4 addresses to hand one to each customer. Many customers don't need a unique IPv4 address, these are the ones you switch to DS-Lite. Those that do require a unique IPv4 you leave on full dual stack for as long as you can. The authors of DS-lite say it's because running a dual stack network is hard. It is harder. You clearly don't share that view, so in your view what's wrong with dual stack with IPv4 for everyone then, whether they need a unique address or not? Dual stack for everyone was feasible 5 years ago. It isn't anymore, that transition plan has sailed and almost no one got on board. Because there aren't enough addresses to go around and there hasn't been for years. PNAT is a kludge to work around that fact. When you can't give every customer their own IPv4 address yet you still need to provide IPv4 connectivity you need to work out how to share those addresses you have efficiently. Given double PNAT or DS-Lite I know which one I prefer. DS-Lite allows lots of the tricks used with PNAT to continue to work. Those tricks will just stop working with double PNAT. DS-lite requires CGN, so does dual stack without enough IPv4 addresses. This is probably the wrong forum for a DS-lite debate. I'm sure people have a use for it, they actually might have gear that can only do IPv4 OR IPv6 but not both or something. My problem with it is that it's being seen as a solution for a whole lot of people, when in reality it's a solution for a small number of people. It's not the only solution. There are others and customers and ISP's will need to work out what is best for their collective requirements. It is a reasonable fit for residentual ISP's as the CPE PNAT is really very inefficient at conserving addresses and by splitting the PNAT across 2 co-operating boxes you can get the address utilisation efficency we now need in IPv4 to cover all the short sightedness that has got us to the place where we need things other than dual stack. Thanks for the point about the tunnel brokers though, I missed that, I'll update this tomorrow with any suggestions I get before then. -- Nathan Ward -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
RE: ISP customer assignments
-Original Message- From: Justin To go along with Dan's query from above, what are the preferred methods that other SPs are using to deploy IPv6 with non-IPv6-capable edge hardware? We too have a very limited number of dialup customers and will never sink another dollar in the product. Unfortunately I also have brand-new ADSL2+ hardware that doesn't support IPv6 and according to the vendors (Pannaway) never will. We also have CMTSs that don't support IPv6, even though they too are brand-new. Those CMTSs top out at DOCSIS 2.0 and the vendor decided not to allow IPv6 to the CPEs regardless of the underlying CM's IPv6 support or lack thereof (like Cisco allowed for example). Are providers implementing tunneling solutions? Pros/cons of the various solutions? My first (potentially ignorant) response would be to get your acquisitions people aligned with your business, and by that I mean they should be making a concerted effort to only buy IPv6 capable gear, especially when IPv6 is coming to you within that gears lifecycle. I guess your customers will need to tunnel, as long as you give them a public IP they have 6to4 (and possibly Teredo, tunnel broker) - but native is better.
Re: ISP customer assignments
Nathan Ward, please stand up. Adrian On Tue, Oct 13, 2009, TJ wrote: -Original Message- From: Justin To go along with Dan's query from above, what are the preferred methods that other SPs are using to deploy IPv6 with non-IPv6-capable edge hardware? We too have a very limited number of dialup customers and will never sink another dollar in the product. Unfortunately I also have brand-new ADSL2+ hardware that doesn't support IPv6 and according to the vendors (Pannaway) never will. We also have CMTSs that don't support IPv6, even though they too are brand-new. Those CMTSs top out at DOCSIS 2.0 and the vendor decided not to allow IPv6 to the CPEs regardless of the underlying CM's IPv6 support or lack thereof (like Cisco allowed for example). Are providers implementing tunneling solutions? Pros/cons of the various solutions? My first (potentially ignorant) response would be to get your acquisitions people aligned with your business, and by that I mean they should be making a concerted effort to only buy IPv6 capable gear, especially when IPv6 is coming to you within that gears lifecycle. I guess your customers will need to tunnel, as long as you give them a public IP they have 6to4 (and possibly Teredo, tunnel broker) - but native is better. -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA -
Re: ISP customer assignments
No idea, I haven't looked at that stuff in a while. But I would assume so, as it's easier to build a foundation than jumping straight to something difficult? Or did you learn calculus in grade school? Just askin' ;) Scott Mark Newton wrote: On 13/10/2009, at 2:02 PM, Scott Morris wrote: I happen to train people at CCIE level. I also happen to do consulting, implementation, and design work. In my training environment, there are all sorts of re-thinking of what/how things are being taught even within the confines of comparison to a lab environment. Does the CCNA exam still ask questions about RIP and classful addressing? Just askin' :-) - mark -- Mark Newton Email: new...@internode.com.au (W) Network Engineer Email: new...@atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 Network Man - Anagram of Mark Newton Mobile: +61-416-202-223
Re: ISP customer assignments
On 2009-10-13, at 07:39, Scott Morris wrote: No idea, I haven't looked at that stuff in a while. But I would assume so, as it's easier to build a foundation than jumping straight to something difficult? I've found RIP to be a reasonable way to teach the concept of a routing protocol, since the protocol is very simple and you can always close with don't ever use this. But teaching classful routing and addressing is just moronic. It's a foundation that nothing is built on any more, and makes no sense to teach outside of a history class. Or did you learn calculus in grade school? Just askin' ;) Yes, since you asked, but your presumption is faulty. Joe
Re: ISP customer assignments
While I may agree that teaching classful routing is stupid, the addressing part lets people start getting the concept of binary. While I'd love to think that people coming out of the school system have a grasp of simple mathematical skills, more and more I'm finding that's not the case.I wouldn't spend a LOT of time with it, and I certainly wouldn't LEAVE at classful addressing, but it's a foundational step. Why is the presumption faulty? If you did calculus, more power to you. However, you still needed a foundation before a pseudo-random collection of letters and numbers together would make any sense. ;) I learned long ago that not everyone can learn in the same fashion that I do. So there's a path to everything with foundations. Some people have a hard time subnetting IPv4 on varying boundaries. More people have a hard time subnetting IPv6 on varying boundaries. While I don't have a problem with either I have to find ways to fix those that do while teaching. And typically it's missing foundation skills. But anyway, I don't think that's the important part! My point was more about not assuming that just because someone is teaching that they don't have a realistic set of experiences to go with it as the poster from APNIC pointed out. Just my two cents, Scott Joe Abley wrote: On 2009-10-13, at 07:39, Scott Morris wrote: No idea, I haven't looked at that stuff in a while. But I would assume so, as it's easier to build a foundation than jumping straight to something difficult? I've found RIP to be a reasonable way to teach the concept of a routing protocol, since the protocol is very simple and you can always close with don't ever use this. But teaching classful routing and addressing is just moronic. It's a foundation that nothing is built on any more, and makes no sense to teach outside of a history class. Or did you learn calculus in grade school? Just askin' ;) Yes, since you asked, but your presumption is faulty. Joe
Re: ISP customer assignments
Ok, fair enough. I was working on the presumption not so much that it was simpler but more than it provided a logical structure. Having some framework to start with provides a base. True that binary is binary is binary... But rather than just an amorphous collection of x-number of bits, there's some initial rhyme and reason. Explaining that, getting buy in, and understanding the limitations therein will make the next progression to VLSM simpler to grasp. At least in my opinion. :) Scott Joe Abley wrote: On 2009-10-13, at 08:05, Scott Morris wrote: While I may agree that teaching classful routing is stupid, the addressing part lets people start getting the concept of binary. That's true of classless addressing, too. When students have problems with non-octet bit boundaries, that just means you start with mask lengths that are multiples of 8. While I'd love to think that people coming out of the school system have a grasp of simple mathematical skills, more and more I'm finding that's not the case.I wouldn't spend a LOT of time with it, and I certainly wouldn't LEAVE at classful addressing, but it's a foundational step. Why is the presumption faulty? You were suggesting that classful addressing is reasonable to teach because it's simpler. It's not simpler, and in a modern-day context it's just wrong. Joe
Re: ISP customer assignments
Heh - Every time I try to say something close to don't ever use this or not really used anymore WRT RIP I get a student or three that is using it, and in fact it is there only option due to certain vendors' choices of what routing protocols to support on certain classes of gear. /TJ ... really hoping those certain vendors choose OSPFv3 (or ISIS, I really don't care - anything instead of RIPng :P ) for IPv6. On Tue, Oct 13, 2009 at 7:53 AM, Joe Abley jab...@hopcount.ca wrote: On 2009-10-13, at 07:39, Scott Morris wrote: No idea, I haven't looked at that stuff in a while. But I would assume so, as it's easier to build a foundation than jumping straight to something difficult? I've found RIP to be a reasonable way to teach the concept of a routing protocol, since the protocol is very simple and you can always close with don't ever use this. But teaching classful routing and addressing is just moronic. It's a foundation that nothing is built on any more, and makes no sense to teach outside of a history class. Or did you learn calculus in grade school? Just askin' ;) Yes, since you asked, but your presumption is faulty. Joe -- /TJ
Re: ISP customer assignments
On Tue, 13 Oct 2009 07:39:46 EDT, Scott Morris said: No idea, I haven't looked at that stuff in a while. But I would assume so, as it's easier to build a foundation than jumping straight to something difficult? Unfortunately, classful addressing is a foundation for networking the same way Roman numerals were a foundation for arithmetic. Both are the way we used to do it, neither is relevant anymore, and once learned, both are bad habits that actively inhibit learning the more useful methods... And yes, as a matter of fact, I *did* start learning calculus in grade school. Have to admit that partial derivatives stumped me until middle school, though. pgpVX8PuwxRdX.pgp Description: PGP signature
Re: ISP customer assignments
Doug Barton wrote: Out of curiosity who is conducting this class and what was their rationale for using /127s? It's a GK class. The instructor seems to be fairly knowledgeable and has a lengthy history consulting on and deploying IPv6. The class seems to be geared much more towards enterprise though instead of service providers. That's very unfortunate considering that every one of the 15 people in this class either works for or contracts to a SP. Still the instructor has some SP knowledge so he fills in the blanks when possible. We're all thinking like SPs though and we ask the SP-oriented questions which usually helps us steer the course the direction we want. I wish GK and other training companies would start offering classes geared towards SPs. They could easily take the existing courseware, add a couple days at the end and interject useful SP info into the earlier days. All that extra info could be specifically aimed at SPs. He didn't really give much of a reason for the /127s yet. I think it's coming up in a later session. I think it basically boiled down to whether or not the customer would actually use anything bigger. I'll write back when we get into that discussion. Justin
Re: ISP customer assignments
On 13/10/09 15:33, Justin Shore wrote: He didn't really give much of a reason for the /127s yet. I think it's coming up in a later session. I think it basically boiled down to whether or not the customer would actually use anything bigger. I'll write back when we get into that discussion. Anything other than /64 removes the possibility of using privacy (aka temporary) addresses, enabled on Vista and above by default (net.ipv6.conf.all.use_tempaddr on Linux). For a single prefix a host may have by default up to 8 global unicast addresses - 1 EUI-64 and 7 privacy.
Re: ISP customer assignments
On 12/10/09 21:34 -0500, Justin Shore wrote: To go along with Dan's query from above, what are the preferred methods that other SPs are using to deploy IPv6 with non-IPv6-capable edge hardware? We too have a very limited number of dialup customers and will never sink another dollar in the product. Unfortunately I also have brand-new ADSL2+ hardware that doesn't support IPv6 and according to the vendors (Pannaway) never will. I don't recall if Pannaway is a layer 3 or layer 2 DSLAM, but we have a mix of Calix C7 (ATM) and Calix E5 (Ethernet) gear in our network. We're kinda in the same boat, but we expect to be able to gracefully transition to dual stacked IPv4/IPv6 without having to replace DSL modems, by reconfiguring the modems into bridged mode and leaving the layer 3 up to the customer's router. We're also in the process of budgeting for a new broadband aggregation router next year that will handle IPv6. Ask Pannaway if they can bridge traffic (either ATM PVC, or Ethernet QinQ/VLAN per subscriber) up to a broadband aggregator, like a Redback or Cisco. -- Dan White
Re: ISP customer assignments
George Michaelson wrote: As a point of view on this, a member of staff from APNIC was doing a Masters of IT in the last 3-4 years, and had classfull A/B/C addressing taught to her in the networks unit. She found it quite a struggle to convince the lecturer that reality had moved on and they had no idea about CIDR. I'm ok with teaching it to beginners to explain where we came from but that should be it. It should be made excruciatingly clear in the training that it's no longer done that way because we found a MUCH better way of doing things. That said I still occasionally refer to networks in classful terms and I can think of several network engineers who have years of enterprise experience that still don't understand CIDR. Justin
Re: ISP customer assignments
On 2009-10-13, at 08:05, Scott Morris wrote: While I may agree that teaching classful routing is stupid, the addressing part lets people start getting the concept of binary. That's true of classless addressing, too. When students have problems with non-octet bit boundaries, that just means you start with mask lengths that are multiples of 8. While I'd love to think that people coming out of the school system have a grasp of simple mathematical skills, more and more I'm finding that's not the case.I wouldn't spend a LOT of time with it, and I certainly wouldn't LEAVE at classful addressing, but it's a foundational step. Why is the presumption faulty? You were suggesting that classful addressing is reasonable to teach because it's simpler. It's not simpler, and in a modern-day context it's just wrong. Joe
Re: ISP customer assignments
On Mon, Oct 12, 2009 at 8:32 PM, Scott Morris s...@emanon.com wrote: How many addresses do you like on point-to-point circuits? Scott I allocate a /64, but currently I configure only a /127 subnet on the actual interface. That prevents the neighbor table explosion/NS/ND traffic flooding challenges that can occur otherwise if you configure the link as a /64, and some not-nice person decides to start ping sweeping or nmapping the subnet; your router has to send out NS messages for every address in the /64 being probed, update the neighbor table with the incomplete entry, then flush it out when no ND message is seen. On a point-to-point link between routers you're never going to run stateless autoconfiguration, so there's not much downside to configuring it as a /127. Still...just in case, I do allocate the whole /64 for the link, so that if in the future it turns out that for some reason it really, *really* does have to be a /64 configured on it, I can make the change just by adjusting masks on each end, rather than having to actually renumber the entire network. *shrug* As always, your mileage will vary, but this has worked out well for me so far. Matt
Re: ISP customer assignments
How many addresses do you like on point-to-point circuits? That will become one of those great interview questions, because anyone who says something like a /127 or a /64 will be someone that you probably don't want to hire. The right answer is to explain that there are some issues surrounding the choice of addressing on point-to-point circuits and there has even been an RFC published discussing these issues, RFC 3627 http://www.ietf.org/rfc/rfc3627.txt The right decision for one network, or for one point in the topology, might not be the right decision for some other place. Some people may learn this by rote as a rule to always use a /126 or a /112 for point-to-point links, but even then it is best to understand why. --Michael Dillon
Re: ISP customer assignments
I'm ok with teaching it to beginners to explain where we came from but that should be it. But why does that have to be done first? Why can't they teach current best practice in addressing, and then point out that historically it was done different but that caused problems which led to today's system? That said I still occasionally refer to networks in classful terms and I can think of several network engineers who have years of enterprise experience that still don't understand CIDR. I'm very careful about classful terminology because I work with a team of engineers who still occasionally must deal with a customer network (using very old gear) which requires class C addressing. For those who don't know what a Class C address is, it is an IP address in the range 192.0.0.0 to 223.255.255.255, i.e. it begins with binary 110, and the network prefix is fixed at /24. This means that 10.2.3/24 is not a class C address, and 192.2/16 is not a legal address block. --Michael Dillon
Re: ISP customer assignments
On 2009-10-13, at 14:46, Matthew Petach wrote: I allocate a /64, but currently I configure only a /127 subnet on the actual interface. For BRAS/PPPoE deployments you're dealing with a point-to-point link, so in principle you can number the endpoints using whatever you want. They're just host addresses and interface routes when it comes down to it. There's no need to number both ends within a single conventional subnet. In the test deployment I did earlier in the year I defined a pool of link addresses per BRAS (one /64 prefix per BRAS) and handed out one to each subscriber using ND/RA after IPv6CP had completed. To the subscriber that looked like a /128 host route, with some other arbitrary address on the far side. (We could have done it with RADIUS too, but having a static link address didn't seem particularly important.) A sub-side static /48 was then assigned via RADIUS and a route installed on the BRAS side, with DHCPv6 PD available as an option for clients who want auto-configuration rather than static config. It seemed to work. BRAS was a Juniper E-series (test box was an ERX310). Joe
Re: ISP customer assignments
On Oct 13, 2009, at 9:56 PM, Joe Abley wrote: On 2009-10-13, at 14:46, Matthew Petach wrote: I allocate a /64, but currently I configure only a /127 subnet on the actual interface. For BRAS/PPPoE deployments you're dealing with a point-to-point link, so in principle you can number the endpoints using whatever you want. They're just host addresses and interface routes when it comes down to it. There's no need to number both ends within a single conventional subnet. In the test deployment I did earlier in the year I defined a pool of link addresses per BRAS (one /64 prefix per BRAS) and handed out one to each subscriber using ND/RA after IPv6CP had completed. To the subscriber that looked like a /128 host route, with some other arbitrary address on the far side. (We could have done it with RADIUS too, but having a static link address didn't seem particularly important.) A sub-side static /48 was then assigned via RADIUS and a route installed on the BRAS side, with DHCPv6 PD available as an option for clients who want auto-configuration rather than static config. It seemed to work. BRAS was a Juniper E-series (test box was an ERX310). We run roughly the same, although we skip the whole globalscope address on the PPP, running localscope only works for the CPE we tested so far. MarcoH
Re: ISP customer assignments
Dan White wrote: I don't recall if Pannaway is a layer 3 or layer 2 DSLAM, but we have a mix of Calix C7 (ATM) and Calix E5 (Ethernet) gear in our network. We're kinda in the same boat, but we expect to be able to gracefully transition to dual stacked IPv4/IPv6 without having to replace DSL modems, by reconfiguring the modems into bridged mode and leaving the layer 3 up to the customer's router. We're also in the process of budgeting for a new broadband aggregation router next year that will handle IPv6. Ask Pannaway if they can bridge traffic (either ATM PVC, or Ethernet QinQ/VLAN per subscriber) up to a broadband aggregator, like a Redback or Cisco. In Pannaway's case they want to pretend to be in the router business and we ended up buying their BARs. Their DSLAMs (BASs) are aggregated into their BARs and the BAR ring terminates on my Cisco core. I would love to eliminate the BARs from the equation but that's not an option. I've been by several (dozen) people that their Minnesota Pannaway office stopped selling the BARs and instead worked with Cisco for aggregation. I've also been told by Cisco folks that numerous sites are trying to get Cisco to take the Pannaway BARs in on trade-in. It would appear that no one like the BARs. Occam did it right. They didn't try to pretend to be in the router business. They stuck with L2. We're also in a bit of a pickle because we're using smart DSL modems/routers. I've argued for years for dumb DSL modems that had no routing/NAT capabilities at all. Unfortunately I didn't win that argument. Now we have what amount to CPEs that do not support IPv6. Whether they'll even pass IPv6 packets in a bridging mode is yet to be determined. Since some of the modems are Pannaway and given my experience with Pannaway and trying to bridge things over it without Pannaway messing with it in the middle (VLAN carrying IS-IS for example), I fully expect problems... It's no secret; I do not recommend Pannaway products based on my firsthand experience. Their SE actually told us 2 years ago that IPv6 was a fad and would never be adopted. Justin
Re: ISP customer assignments
On 13/10/09 15:32 -0500, Justin Shore wrote: one like the BARs. Occam did it right. They didn't try to pretend to be in the router business. They stuck with L2. Occam did it partially right. They're half-bridging only - not true layer 2 to an aggregator (which is not necessary in their scenario). The problem with the access vendor doing half-bridging is that they have to be very layer-3 smart, and Occam was not quite there for IPv6 last time I worked with them (about 6 months ago). It's no secret; I do not recommend Pannaway products based on my firsthand experience. Their SE actually told us 2 years ago that IPv6 was a fad and would never be adopted. I haven't really been happy with any DSL vendor's response to my questions about IPv6. We happened to choose Calix, which is not particularly IPv6 friendly, but were successful in getting commitments from them to support IPv6 pass through. I have little doubt that Pannaway could implement IPv6, they just need to get enough demand from customers to make it worth their while. -- Dan White
Re: ISP customer assignments
Dan White wrote: Occam did it partially right. They're half-bridging only - not true layer 2 to an aggregator (which is not necessary in their scenario). The problem with the access vendor doing half-bridging is that they have to be very layer-3 smart, and Occam was not quite there for IPv6 last time I worked with them (about 6 months ago). When we did a RFP with them they didn't support v6 yet but they also wouldn't get in the way of passing v6 over them (minus the DHCP snooping/learning features of course). That was 2 years ago. I haven't looked at them since but they said that they'd work on it. I haven't really been happy with any DSL vendor's response to my questions about IPv6. We happened to choose Calix, which is not particularly IPv6 friendly, but were successful in getting commitments from them to support IPv6 pass through. None of the FTTH vendors we vetted supported v6 but at least a few said that they'd work on it. Pannaway's response though was priceless. I have little doubt that Pannaway could implement IPv6, they just need to get enough demand from customers to make it worth their while. Pannaway was bought a while back by Enablence. Hopefully they will drive a bit more clue into the products. Hopefully that SE isn't there anymore or if he is hopefully he's not driving product development. His other 2 answers about QoS not being needed because our links were sustaining saturation (microbursts anyone?) and that we didn't need an IGP because our network wasn't big enough and that static routing would do (for just shy of 100 routing devices in 3 POPs) was the icing on the cake. Unfortunately the decision was made to eat the cake anyway. Justin
Re: ISP customer assignments
So far, I have only dabbled with IPv6, but my reading of the RFCs is that VLSM for lengths beyond /64 is not required. Subsequently, to use anything longer is an enormous gamble in an enterprise environment. I envision upgrading code one day and finding that your /127 isn't supported any more and they forgot to mention it. I'll stick to /64, though it does seem a horrible waste of space. Someone else might have read the RFC differently though. Eric Clark
Re: ISP customer assignments
eric clark wrote: So far, I have only dabbled with IPv6, but my reading of the RFCs is that VLSM for lengths beyond /64 is not required. Subsequently, to use anything longer is an enormous gamble in an enterprise environment. I envision upgrading code one day and finding that your /127 isn't supported any more and they forgot to mention it. I'll stick to /64, though it does seem a horrible waste of space. Someone else might have read the RFC differently though. I'm sure there's an RFC somewhere talking about Classful addressing pre-CIDR. Perhaps we should stop using CIDR in IPv4. It might stop working one day. ;) Operational reality helps to refine RFCs. Many people are already using longer prefixes for infrastructure and other purposes, so it's unlikely to go away. The only real issue is that some old hardware may not support prefixes longer than /64 in hardware and so may drop to software routing. I don't know of any examples of this though. adam.
Re: ISP customer assignments
Once upon a time, Michael Dillon wavetos...@googlemail.com said: How many addresses do you like on point-to-point circuits? That will become one of those great interview questions, because anyone who says something like a /127 or a /64 will be someone that you probably don't want to hire. The right answer is to explain that there are some issues surrounding the choice of addressing on point-to-point circuits and there has even been an RFC published discussing these issues, RFC 3627 http://www.ietf.org/rfc/rfc3627.txt Still learning here, so please go easy... I read the above, and I see section 4 item 3 says: The author feels that if /64 cannot be used, /112, reserving the last 16 bits for node identifiers, has probably the least amount of drawbacks (also see section 3). I guess I'm missing something; what in section 3 is this referring to? I can understand /64 or /126 (or maybe /124 if you were going to delegate reverse DNS?), but why /112 and 16 bits for node identifiers on a point-to-point link? -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: ISP customer assignments
On Oct 13, 2009, at 4:26 PM, Chris Adams wrote: Once upon a time, Michael Dillon wavetos...@googlemail.com said: How many addresses do you like on point-to-point circuits? That will become one of those great interview questions, because anyone who says something like a /127 or a /64 will be someone that you probably don't want to hire. The right answer is to explain that there are some issues surrounding the choice of addressing on point-to-point circuits and there has even been an RFC published discussing these issues, RFC 3627 http://www.ietf.org/rfc/rfc3627.txt Still learning here, so please go easy... I read the above, and I see section 4 item 3 says: The author feels that if /64 cannot be used, /112, reserving the last 16 bits for node identifiers, has probably the least amount of drawbacks (also see section 3). I guess I'm missing something; what in section 3 is this referring to? I can understand /64 or /126 (or maybe /124 if you were going to delegate reverse DNS?), but why /112 and 16 bits for node identifiers on a point-to-point link? I'm actually completely unclear why people would use anything but a / 126 in 90% or more of cases. For all intensive purposes a /126 translates to a /30 in IPv4. Do people assign /24's to their point to point links today with IPv4? What's the point of a /64 on a point to point link? I'm not clear why people would intentionally be so frivolous with their IP space simply for the sake of because I can.
Re: ISP customer assignments
Chris Adams wrote: I guess I'm missing something; what in section 3 is this referring to? I can understand /64 or /126 (or maybe /124 if you were going to delegate reverse DNS?), but why /112 and 16 bits for node identifiers on a point-to-point link? The only thing special about /112 is that it is on a : boundary so it makes for some nice numbering plans: Let's say you set aside 2001::0:1::/64 for /112's link 1: 2001::0:1::1:1 2001::0:1::1:2 link 2: 2001::0:1::2:1 2001::0:1::2:2 This :1, :2 arrangement seems to be common but for internal links you could make the last hextet be a unique id for the specific router. That could use more than a few bits in a large network. - Kevin
Re: ISP customer assignments
That was the point. :) Scott Matthew Petach wrote: On Mon, Oct 12, 2009 at 8:32 PM, Scott Morris s...@emanon.com mailto:s...@emanon.com wrote: How many addresses do you like on point-to-point circuits? Scott I allocate a /64, but currently I configure only a /127 subnet on the actual interface. That prevents the neighbor table explosion/NS/ND traffic flooding challenges that can occur otherwise if you configure the link as a /64, and some not-nice person decides to start ping sweeping or nmapping the subnet; your router has to send out NS messages for every address in the /64 being probed, update the neighbor table with the incomplete entry, then flush it out when no ND message is seen. On a point-to-point link between routers you're never going to run stateless autoconfiguration, so there's not much downside to configuring it as a /127. Still...just in case, I do allocate the whole /64 for the link, so that if in the future it turns out that for some reason it really, *really* does have to be a /64 configured on it, I can make the change just by adjusting masks on each end, rather than having to actually renumber the entire network. *shrug* As always, your mileage will vary, but this has worked out well for me so far. Matt
Re: ISP customer assignments
While entirely possible, I actually view it going the other way. RFC 3627 points out some nice issues as far as DAD and anycast operation is concerned, but what I'd see (just my random opinion as I haven't bothered to write an RFC) is that it would make entirely much more sense to come up with a structure to STOP the anycast performance on a link that is point-to-point. While there are 340 undecillion addresses, that doesn't mean we need to waste a /64 on a link that will possibly only have two addresses anyway. My two cents. Scott eric clark wrote: So far, I have only dabbled with IPv6, but my reading of the RFCs is that VLSM for lengths beyond /64 is not required. Subsequently, to use anything longer is an enormous gamble in an enterprise environment. I envision upgrading code one day and finding that your /127 isn't supported any more and they forgot to mention it. I'll stick to /64, though it does seem a horrible waste of space. Someone else might have read the RFC differently though. Eric Clark
Re: ISP customer assignments
In a message written on Tue, Oct 13, 2009 at 06:26:20PM -0500, Chris Adams wrote: The author feels that if /64 cannot be used, /112, reserving the last 16 bits for node identifiers, has probably the least amount of drawbacks (also see section 3). I guess I'm missing something; what in section 3 is this referring to? I can understand /64 or /126 (or maybe /124 if you were going to delegate reverse DNS?), but why /112 and 16 bits for node identifiers on a point-to-point link? We use /112's, and do so for two (and a half) reasons: 1) If you think of all possible network to network interconnects they include the simple case like a single router on both ends, but they also include cases like two routers on one or both ends, and optionally with VRRP/HSRP. Maximally it appears 6 IP's may be required (two routers both ends, plus vrrp on each, statics at the VRRP). So it makes sense to have a 8 or 16 block of IP's per link so you never have to renumber the link if you switch these configurations. 2) Colon's separate 16 bit chunks in IPv6. /112's allow ::1, ::2 to be your IP's. The half a reason, if you have a /64 dedicate to point to point links, and use /112's, you have 2^(112-64) possible links. That's 281 trillion point to point links. Given 1, and 2, and the numbers /127's, /126's, /125's don't make any sense when you can standardize on one size fits all, and never run out. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpoNZzF1ehvR.pgp Description: PGP signature
Re: ISP customer assignments
On Tue, Oct 13, 2009 at 6:34 PM, Cord MacLeod cordmacl...@gmail.com wrote: IPv4? What's the point of a /64 on a point to point link? I'm not clear IP Addressing uniformity and simplicity. Use of /127s for Point-to-Point links introduces addressing complexity that may be avoided in V6: the scarcity of IPs necessitated it in V4 .At least /112 lies on an even 16-bit boundary, and that makes it the longest prefix that is a very good choice, if you do need a non-standard mask. Unless you have only a /32 of V6 space and 1 billion P2Pt links you need (or similar scenario), there is no utility in practicing rampant prefix length expansion, for the purpose of conservation (there may be other reasons such as preventing autoconfig). For all intensive purposes a /126 translates to a /30 in IPv4. Do people assign /24's to their point to point links today with Not really; there's a massive difference of scale.Say there's a big vat that contains all gold in the universe, you get to bring home one bucket of gold flakes to allocate to your customers. In the V4 universe, well you got a /19.. You got a 60 kilogram bucket, and a /30 represents a 1 troy ounce scoop taken out of that bucket.. In the V6 universe, even if you got a measly /48: one /64 from that is a 1 troy ounce gold flake out of your 2000 kilogram bucket. Should you really be worried about cutting up that flake? In reality... if you're an ISP the worst you have is a /32, you can think of a /48 that way, you do have 65536 of those /48s, also known as a 133,588,416kg bucket, since your /32 has a maximum of 4 billion /64s. Normally when you have a P2P link, it will mean you connect an end site also: that end site gets a /48 (Per the justification that allows you as an ISP to get a /32, such a large allocation). After assigning 65536 /64s, or 256 /64s (if you give out /56s to end sites) which you already do for each _end site_ as standard address allocation practice in V6, what's another single /64, seriously? -- -J
Re: ISP customer assignments
Once upon a time, Leo Bicknell bickn...@ufp.org said: 2) Colon's separate 16 bit chunks in IPv6. /112's allow ::1, ::2 to be your IP's. Yeah, this is what I forgot about. Makes sense now. Another (quite possibly dumb :-) ) few questions come to mind about IPv6 assignment: I would expect you just assign static addresses to servers. Are there pros/cons to using /64 or something else there? If I'm statically assigning IP (and DNS, etc. servers) info, why would I not just configure the gateway there as well (especially if you just make all local router interfaces ::1)? What about web-hosting type servers? Right now, I've got a group of servers in a common IPv4 subnet (maybe a /26), with a /24 or two routed to each server for hosted sites. What is the IPv6 equivalent? I can see a /64 for the common subnet, but what to route for aliased IPs for web hosts? It is kind of academic right now, since our hosting control panel software doesn't handle IPv6, but I certainly won't be putting 2^64 sites on a single server. Use a /112 here again as well? Use a /64 per server because I can? What about anycast-type addresses (e.g. DNS servers)? I route a few server IPv4 /32s around in my network; do you assign a /128, a /64 (with only one address in use), a /112, or something else? -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: ISP customer assignments
On Tue, 13 Oct 2009 09:33:03 -0400, Justin Shore jus...@justinshore.com wrote: He didn't really give much of a reason for the /127s yet. I think it's coming up in a later session. I think it basically boiled down to whether or not the customer would actually use anything bigger. I'll write back when we get into that discussion. It's the IPv6 equiv of an IPv4 /30 link network. Then a /64 or whatever can be aimed to that link address. This is exactly what Bellsouth does for business DSL: the link has a dynamic address and your netblock is then routed to it. (this is confusing and unworkable for a lot of cheap hardware.)
Re: ISP customer assignments
In a message written on Tue, Oct 13, 2009 at 08:14:40PM -0500, Chris Adams wrote: I would expect you just assign static addresses to servers. Are there pros/cons to using /64 or something else there? If I'm statically assigning IP (and DNS, etc. servers) info, why would I not just configure the gateway there as well (especially if you just make all local router interfaces ::1)? All of our servers are in binary coded hex. :) That is, if your IPv4 address is 10.12.3.187, your IPv6 address is A:B:C:D::187. The router is ::1, just as in IPv4, and servers have static routes. We still use /64's everywhere. You may want to use temporary (privacy) addresses outbound. You many want to allow a server to use EUI-64 to get an address while doing an install, or similar. What about anycast-type addresses (e.g. DNS servers)? I route a few server IPv4 /32s around in my network; do you assign a /128, a /64 (with only one address in use), a /112, or something else? /128's for loopbacks, anycast addreses, and similar here. Typically out of a loopback /64. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpZg7bmq3t4a.pgp Description: PGP signature
RE: ISP customer assignments
What about anycast-type addresses (e.g. DNS servers)? I route a few server IPv4 /32s around in my network; do you assign a /128, a /64 (with only one address in use), a /112, or something else? Yes, on any sort of multi-access segment you really should use /64s. A little less stringent on an all router segment perhaps, but even then I shoot for /64s on anything that is not a PtP link ... /TJ -Original Message- From: Chris Adams [mailto:cmad...@hiwaay.net] Sent: Tuesday, October 13, 2009 9:15 PM To: nanog@nanog.org Subject: Re: ISP customer assignments Once upon a time, Leo Bicknell bickn...@ufp.org said: 2) Colon's separate 16 bit chunks in IPv6. /112's allow ::1, ::2 to be your IP's. Yeah, this is what I forgot about. Makes sense now. Another (quite possibly dumb :-) ) few questions come to mind about IPv6 assignment: I would expect you just assign static addresses to servers. Are there pros/cons to using /64 or something else there? If I'm statically assigning IP (and DNS, etc. servers) info, why would I not just configure the gateway there as well (especially if you just make all local router interfaces ::1)? What about web-hosting type servers? Right now, I've got a group of servers in a common IPv4 subnet (maybe a /26), with a /24 or two routed to each server for hosted sites. What is the IPv6 equivalent? I can see a /64 for the common subnet, but what to route for aliased IPs for web hosts? It is kind of academic right now, since our hosting control panel software doesn't handle IPv6, but I certainly won't be putting 2^64 sites on a single server. Use a /112 here again as well? Use a /64 per server because I can? What about anycast-type addresses (e.g. DNS servers)? I route a few server IPv4 /32s around in my network; do you assign a /128, a /64 (with only one address in use), a /112, or something else?
Re: ISP customer assignments
Once upon a time, Nathan Ward na...@daork.net said: On 14/10/2009, at 2:14 PM, Chris Adams wrote: What about web-hosting type servers? Right now, I've got a group of servers in a common IPv4 subnet (maybe a /26), with a /24 or two routed to each server for hosted sites. What is the IPv6 equivalent? I can see a /64 for the common subnet, but what to route for aliased IPs for web hosts? It is kind of academic right now, since our hosting control panel software doesn't handle IPv6, but I certainly won't be putting 2^64 sites on a single server. Use a /112 here again as well? Use a /64 per server because I can? Why route them to the servers? I would just put up a /64 for the web servers and bind addresses to your ethernet interface out of that /64 as they are used by each site. I guess you might want to route them to the servers to save ND entries or something on your router? In the past, we saw issues with thousands of ARP entries (it has been a while and I don't remember what issues now though). Moving a block from one server to another didn't require clearing an ARP cache (and triggering a couple of thousand new ARP requests). Also, it is an extra layer of misconfiguration-protection: if the IPs are routed, accidentally assigning the wrong IP on the wrong server didn't actually break any existing sites (and yes, that is a lesson from experience). Of course, with IPv4, you never assigned a large enough block to begin with that would anticipate all growth, so routing additional blocks was a lot easier than changing blocks, cleaner than secondary IPs multiplying like crazy, etc., etc. None of that would be an issue with a single /64. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: ISP customer assignments
On 14/10/2009, at 3:49 PM, Chris Adams wrote: Once upon a time, Nathan Ward na...@daork.net said: On 14/10/2009, at 2:14 PM, Chris Adams wrote: What about web-hosting type servers? Right now, I've got a group of servers in a common IPv4 subnet (maybe a /26), with a /24 or two routed to each server for hosted sites. What is the IPv6 equivalent? I can see a /64 for the common subnet, but what to route for aliased IPs for web hosts? It is kind of academic right now, since our hosting control panel software doesn't handle IPv6, but I certainly won't be putting 2^64 sites on a single server. Use a /112 here again as well? Use a /64 per server because I can? Why route them to the servers? I would just put up a /64 for the web servers and bind addresses to your ethernet interface out of that /64 as they are used by each site. I guess you might want to route them to the servers to save ND entries or something on your router? In the past, we saw issues with thousands of ARP entries (it has been a while and I don't remember what issues now though). Moving a block from one server to another didn't require clearing an ARP cache (and triggering a couple of thousand new ARP requests). Yeah I figured as much. Also, it is an extra layer of misconfiguration-protection: if the IPs are routed, accidentally assigning the wrong IP on the wrong server didn't actually break any existing sites (and yes, that is a lesson from experience). I guess. The advantage of doing it with a single /64 for all of them is that you can move individual sites to other servers without much drama. That might not be useful for everyone of course. -- Nathan Ward
Re: ISP customer assignments
Chris Adams wrote: I guess I'm missing something; what in section 3 is this referring to? I can understand /64 or /126 (or maybe /124 if you were going to delegate reverse DNS?), but why /112 and 16 bits for node identifiers on a point-to-point link? It falls on a 16 bit boundry and is therefore easy to read. some numbering concessions within a vast space exist for the convenience of the poor humans not the machines. I can pick out the host side of the address in a /64 no problem but for some reason I have a trouble finding subnet boundaries on a series of /93s.
Re: ISP customer assignments
On Oct 12, 2009, at 7:34 PM, Justin Shore jus...@justinshore.com wrote: I'm actually taking an IPv6 class right now and the topic of customer assignments came up today (day 1). The instructor was suggesting dynamically allocating /127s to residential customers. I relayed the gist of this thread to him (/48, /56 and /64). I expect to dive deeper into this in the following days in the class. Out of curiosity who is conducting this class and what was their rationale for using /127s? Doug
Re: ISP customer assignments
On 13/10/2009, at 12:54 PM, Doug Barton wrote: On Oct 12, 2009, at 7:34 PM, Justin Shore jus...@justinshore.com wrote: I'm actually taking an IPv6 class right now and the topic of customer assignments came up today (day 1). The instructor was suggesting dynamically allocating /127s to residential customers. I relayed the gist of this thread to him (/48, /56 and /64). I expect to dive deeper into this in the following days in the class. Out of curiosity who is conducting this class and what was their rationale for using /127s? Doug As a point of view on this, a member of staff from APNIC was doing a Masters of IT in the last 3-4 years, and had classfull A/B/C addressing taught to her in the networks unit. She found it quite a struggle to convince the lecturer that reality had moved on and they had no idea about CIDR. I have from time to time, asked people in ACM and IEEE about how one informs the tertiary teaching community about this kind of change. The answers were not inspiring: compared to civil engineering, where compliance issues and re-training by professionals is almost regulated (sorry for the R- word) as a function of professional indemnity insurance and status, its much more common for the syllabus to be under continual review. -George
Re: ISP customer assignments
I'm going to have to pull the mixed-hat on this one. If you are comparing this to a true academia environment, I'd agree with you. Too much theory, not enough reality in things. However, I've yet to see the part about where the person is being trained from. I happen to train people at CCIE level. I also happen to do consulting, implementation, and design work. In my training environment, there are all sorts of re-thinking of what/how things are being taught even within the confines of comparison to a lab environment. But that's a personal point of view trying to keep reality involved and be worthwhile. I'm not trying to open any sort of debate or can of worms here, but just because one is receiving training does not mean the instructor has no functional knowledge of something. I'm interested in hearing the playout on this one as well. How many addresses do you like on point-to-point circuits? Scott George Michaelson wrote: On 13/10/2009, at 12:54 PM, Doug Barton wrote: On Oct 12, 2009, at 7:34 PM, Justin Shore jus...@justinshore.com wrote: I'm actually taking an IPv6 class right now and the topic of customer assignments came up today (day 1). The instructor was suggesting dynamically allocating /127s to residential customers. I relayed the gist of this thread to him (/48, /56 and /64). I expect to dive deeper into this in the following days in the class. Out of curiosity who is conducting this class and what was their rationale for using /127s? Doug As a point of view on this, a member of staff from APNIC was doing a Masters of IT in the last 3-4 years, and had classfull A/B/C addressing taught to her in the networks unit. She found it quite a struggle to convince the lecturer that reality had moved on and they had no idea about CIDR. I have from time to time, asked people in ACM and IEEE about how one informs the tertiary teaching community about this kind of change. The answers were not inspiring: compared to civil engineering, where compliance issues and re-training by professionals is almost regulated (sorry for the R- word) as a function of professional indemnity insurance and status, its much more common for the syllabus to be under continual review. -George
Re: ISP customer assignments
On 13/10/2009, at 2:02 PM, Scott Morris wrote: I happen to train people at CCIE level. I also happen to do consulting, implementation, and design work. In my training environment, there are all sorts of re-thinking of what/how things are being taught even within the confines of comparison to a lab environment. Does the CCNA exam still ask questions about RIP and classful addressing? Just askin' :-) - mark -- Mark Newton Email: new...@internode.com.au (W) Network Engineer Email: new...@atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 Network Man - Anagram of Mark Newton Mobile: +61-416-202-223
Re: ISP customer assignments
How are other providers approaching dial-up? I would presume we are in the same boat as a lot of other folks - we have aging dial-up equipment that does not support IPv6 (3com Total Control). Our customer base has dropped quite a bit, and we have even kicked around the idea dropping that service and forcing customers to purchase broadband service or go elsewhere. Separate these technical issues from IPv6 allocation plans. If you intend to continue running an ISP in two years from now, either make a simple plan and allocate a /48 to every customer site, whether or not they are currently taking an IPv6 service from you. Or, take the slightly more complex plan and allocate a /56 per site where it is known for sure, 100% that the site is a private residence. If it is not, or there is doubt, then allocate a /48. I expect we won't invest any more into dial-up equipment, and when a dial-up customer happens to ask about IPv6 (if ever), we'll strongly encourage them to move to broadband, and as a last resort manually configure a /64 tunnel to them. You might use up a /64 for the two tunnel endpoints, but be sure to allocate the customer at least a /56. What are other providers doing, or considering doing? In general, big providers are not going to attempt to cope with any older equipment that does not fully support IPv6. But small providers will be rather innovative and try things like your tunnel suggestion. After all, if Hurricane Electric can run an IPv6 tunnel broker, why can't you? --Michael Dillon
Re: ISP customer assignments
I would disagree. IPv6 is designed around class boundaries which, in my understanding, are: A layer two network gets assigned a /64 A customer gets assigned a /48 A site gets assigned a /48. It could be a customer site, or one of your many sites or one of a customer's many sites. I interpret site to roughly be within a single building, although a campus type arrangement could be considered a single site if the network architects want to do it that way. An ISP gets assigned a /32 (unless they need more) If your complaint is that all devices in a /64 are going to see IPv6 broadcast/multicast packets from the rest of the devices in that subnet, then don't assign 2^64 devices to that subnet. Indeed! I still don't understand why its infuriating to you, but I can certainly tell that it is. It's purely a case of stage 2 which is a good thing IMHO, since it shows some movement forwards past denial. Confronting the Reality of Emotional Denial and Grief http://www.cu.ipv6tf.org/pdf/CACH2F0T.pdf BTW, that PDF really *is* about IPv6 deployment. --Michael Dillon
Re: ISP customer assignments
There seems to be a variance between It's OK to just give out a /64 to You better be thinking about giving out a /48. I can live in those boundaries and am most likely fine with either. I'm leaning toward a /56 for regular subscribers and a /48 only for business or large scale customers, and undecided on dial-up. How does this sound? The starting point is to give everybody a /48 per site. If a business customer has 3 sites, then give them enough space for a /48 for each site. Could be 3 /48s or could be a /46. But, if you have a lot of residential customers, it is quite reasonable to give them a /56 per site instead. Be prepared for some customers to ask for two /56s because they have a granny-flat or in-law apartment in the house. Also be prepared for some to ask for a /48 because they are running a business at home, or they are technical types who have a their own home network lab. Your plan for /56 to residential subscribers and /48 to business subscribers sounds perfectly fine as long as your systems have some way to accomodate that grey area, either by recording a /48 against a residential subscriber or counting them as a class of business customer that pays a residential rate. Charging a customer extra for more IPv6 addresses just will not fly in a competitive market. --Michael Dillon
Re: ISP customer assignments
Sorry to be a curmudgeon and let me play devil's advocate for a minute. I realize that the address space is enormous; gigantic, even, but if we treat it as cavalierly as you all are proposing, it will get used up. If its treated like an infinite resource that will never, ever be used up as we have done with every other resource on the planet, won't we find ourselves in a heap of trouble? Curtis Michael Dillon wrote: There seems to be a variance between It's OK to just give out a /64 to You better be thinking about giving out a /48. I can live in those boundaries and am most likely fine with either. I'm leaning toward a /56 for regular subscribers and a /48 only for business or large scale customers, and undecided on dial-up. How does this sound? The starting point is to give everybody a /48 per site. If a business customer has 3 sites, then give them enough space for a /48 for each site. Could be 3 /48s or could be a /46. But, if you have a lot of residential customers, it is quite reasonable to give them a /56 per site instead. Be prepared for some customers to ask for two /56s because they have a granny-flat or in-law apartment in the house. Also be prepared for some to ask for a /48 because they are running a business at home, or they are technical types who have a their own home network lab. Your plan for /56 to residential subscribers and /48 to business subscribers sounds perfectly fine as long as your systems have some way to accomodate that grey area, either by recording a /48 against a residential subscriber or counting them as a class of business customer that pays a residential rate. Charging a customer extra for more IPv6 addresses just will not fly in a competitive market. --Michael Dillon
Re: ISP customer assignments
On Thu, Oct 08, 2009 at 10:24:30AM -0400, Curtis Maurand wrote: Sorry to be a curmudgeon and let me play devil's advocate for a minute. I realize that the address space is enormous; gigantic, even, but if we treat it as cavalierly as you all are proposing, it will get used up. If its treated like an infinite resource that will never, ever be used up as we have done with every other resource on the planet, won't we find ourselves in a heap of trouble? At this stage we're only 'being cavalier' with 1/8th of the space. We can be more restrictive with the the other 7/8ths if those predicting rapid consumption turn out to be correct. Right now that would be a nice problem to have. Tim
Re: ISP customer assignments
And I will play devil's advocate to the devil's advocate ... wait, does that make me God's advocate? Nice! On Thu, Oct 8, 2009 at 10:24 AM, Curtis Maurand cmaur...@xyonet.com wrote: Sorry to be a curmudgeon and let me play devil's advocate for a minute. I realize that the address space is enormous; gigantic, even, but if we treat it as cavalierly as you all are proposing, it will get used up. If its treated like an infinite resource that will never, ever be used up as we have done with every other resource on the planet, won't we find ourselves in a heap of trouble? Curtis But the thing is - no-one is proposing we treat it as infinite - just that we treat it the way it was designed to be used. The IETF community did the math and decided a /48 per customer was both scalable and sufficient. The community, by and in large, decided that /56s were more appropriate for small customers and that is fine, even if some still view it as additional, unneeded complexity. My opinion, based on having done the math as well and operational experience to date, seems to jive that /48s (or even moreso /56s) will work. So let's get to it! /TJ
Re: ISP customer assignments
Sorry to be a curmudgeon and let me play devil's advocate for a minute. I realize that the address space is enormous; gigantic, even, but if we treat it as cavalierly as you all are proposing, it will get used up. If its treated like an infinite resource that will never, ever be used up as we have done with every other resource on the planet, won't we find ourselves in a heap of trouble? Of course, you are right. That's why, when some people took a close look at the numbers based on a /48 per site, and published their findings, the RIRs made an adjustment to address allocation policy so that it was acceptable to allocate a /56 for a consumer customer, i.e. private residence of some sort. By doing that, they calculated that they could mitigate the small risk that we would run very low on IPv6 addresses around 100 years from now. Having made the change, we are now confident that there are plenty of IPv6 addresses to last more than a century, which basically means that you and your children and your grand children will all be dead when IPv6 gets close to exhaustion. Geoff Huston wrote this: http://www.potaroo.net/ispcol/2005-07/ipv6size.html to explain the small risk, and his proposals to adjust the HD ratio and go to a /56 for private residential assignments was basically accepted. If only a few of the biggest cable ISPs use the /56 model, then we are OK. I have great confidence that our descendants will avoid the Idiocracy and be capable of designing and deploying a replacement for IPv6 if that is ever needed. http://en.wikipedia.org/wiki/Idiocracy Last time I checked, my taps were still delivering fresh clean toilet water, not Brawndo energy drink. --Michael Dillon
Re: ISP customer assignments
On 08/10/09 11:46 +0100, Michael Dillon wrote: There seems to be a variance between It's OK to just give out a /64 to You better be thinking about giving out a /48. I can live in those boundaries and am most likely fine with either. I'm leaning toward a /56 for regular subscribers and a /48 only for business or large scale customers, and undecided on dial-up. How does this sound? The starting point is to give everybody a /48 per site. If a business customer has 3 sites, then give them enough space for a /48 for each site. Could be 3 /48s or could be a /46. How are other providers approaching dial-up? I would presume we are in the same boat as a lot of other folks - we have aging dial-up equipment that does not support IPv6 (3com Total Control). Our customer base has dropped quite a bit, and we have even kicked around the idea dropping that service and forcing customers to purchase broadband service or go elsewhere. I expect we won't invest any more into dial-up equipment, and when a dial-up customer happens to ask about IPv6 (if ever), we'll strongly encourage them to move to broadband, and as a last resort manually configure a /64 tunnel to them. What are other providers doing, or considering doing? -- Dan White BTC Broadband
Re: ISP customer assignments
Joe Greco jgr...@ns.sol.net writes: the people with the clue-by-fours are over on the IPv6 lists. They've upgraded to clue-by-six's. Not as handy, but will last longer. Bjørn
RE: ISP customer assignments
-Original Message- From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu] Snip - good points all Most of those concerns are in fact mitigated by a well implemented Privacy implementation Which is why I started off by mentioning RFC4191. ;) -End Original Message- And Vista/Win7/etc. make it even more interesting by not doing EUI64 at all. ... Hopefully they have more entropic 'random' values as well ... /TJ
Re: ISP customer assignments
On 05/10/09 22:28 -0400, Ricky Beam wrote: On Mon, 05 Oct 2009 17:13:37 -0400, Dan White dwh...@olp.net wrote: I don't understand. You're saying you have overlapping class boundaries in your network? No. What I'm saying is IPv6 is supposed to be the new, ground-breaking, unimaginably huge *classless* network. Yet, 2 hours into day one, a classful boundary has already been woven into it's DNA. Saying it's I would disagree. IPv6 is designed around class boundaries which, in my understanding, are: A layer two network gets assigned a /64 A customer gets assigned a /48 An ISP gets assigned a /32 (unless they need more) classless because routing logic doesn't care is pure bull. In order for the most basic, fundamental, part (the magic -- holy grail -- address autoconfig) to function, the network has to be a minimum of /64. Even when the reason for that limit -- using one's MAC to form a (supposedly) unique address without having to consult with anything or fire off a single packet -- has long bit the dust; privacy extensions generate addresses at random and have to take steps to avoid address collisions, so continuing to cling to it has to be 64bits is infuriating. IPv6 provides you the opportunity to design your network around your layer two needs, not limited by restrictive layer 3 subnetting needs. If your complaint is that all devices in a /64 are going to see IPv6 broadcast/multicast packets from the rest of the devices in that subnet, then don't assign 2^64 devices to that subnet. I still don't understand why its infuriating to you, but I can certainly tell that it is. -- Dan White BTC Broadband
Re: ISP customer assignments
On 05/10/09 22:53 -0400, Ricky Beam wrote: On Mon, 05 Oct 2009 18:55:35 -0400, Dan White dwh...@olp.net wrote: All of the items in the above list are true of DHCP. ... In an IPv4 world (which is where DHCP lives), it's much MUCH harder to track assignments -- I don't share my DHCP logs with anyone, nor does anyone send theirs to me. From the perspective of remote systems (ie. not on the same network), there is about a 100% chance NAT is involved making it near impossible to individually identify a specific machine, even if it gets the same address every Tuesday when you're at Starbucks for coffee. IPv6 does away with NAT (or it's supposed to); in doing so, the veil is removed and everything that had been hidden from site is now openly displayed. If the host part of your address never changes, then you are instantly identifiable everywhere you go, with zero effort, forever. Use random addresses, and change as often as you like. Why depend on someone else's DHCP server to provide you the addressing uniqueness you desire? -- Dan White BTC Broadband
RE: ISP customer assignments
-Original Message- From: William Herrin [mailto:herrin-na...@dirtside.com] Sent: Monday, October 05, 2009 12:58 PM To: Brian Johnson Cc: nanog@nanog.org Subject: Re: ISP customer assignments /60 - the smallest amount you should allocate to a downstream customer with more than one computer. Anything smaller will cost you extra management overhead from not matching the nibble boundary for RDNS delegation, I have a lack of imagination, I guess. I can't imagine anyone larger than a small residential user being assigned a /60 or less. Therefore, nybble boundary for rDNS delegation only matters if you delegate rDNS for that block. handling multiple routes when the customer grows, not Any customer getting a /60 or less will be dynamically numbered (RA, DHCPv6, whatever), and if more space is needed, should be easily renumbered into a larger prefix. matching the standard /64 subnet size and a myriad other obscure issues. I don't know about myriad but I agree that /64 is the standard subnet size. I am *not* advocating assignments of /60 or less, just pointing out that if you do it, it doesn't have to break. Lee
Re: ISP customer assignments
On 05/10/09 23:23 -0400, Ricky Beam wrote: You underestimate the power of the marketing department and the bean counters. I assure you, residential ISPs are looking for schemes to give out as little address space as possible. That has not been my (limited) experience. If you are aware of any ISPs which are not handing out a reasonable address space to customers, please call them out. The current revision of IPv6 introduces a way to nail down the boundary between network and host. This is fantastic, from an implementation point of view. It simplifies the design of silicon for forwarding engines, etc. And it's 150% Wrong Thinking(tm). IPv6 is classless - PERIOD. The instant some idiot wires /64 into silicon, we're right back to not being able to use x.x.x.0 and x.x.x.255. Addresses are 128-bits; you cannot make any assumptions about what people may or may not be doing with those bits. If I don't use SLAAC, then I'm not bound by it's lame rules. You don't do that. Or at least, you shouldn't do that. :-) We have a fairly reliable DNS system these days... The assumption that IPv6 addresses are harder has not been my experience. A server address of 2610:b8:5::1 is just as easy for me to remember as 67.217.144.1. Granted, auto configured addresses are much harder to remember. And where did DNS get the name/number assignments? In my case, it's either been typed in by ME or automatically updated by DHCP. Anything I put in DNS is a server/router, and gets a static address, just like with IPv4. -- Dan White BTC Broadband
RE: ISP customer assignments
-Original Message- From: robert.e.vanor...@frb.gov [mailto:robert.e.vanor...@frb.gov] Sent: Monday, October 05, 2009 7:41 PM To: nanog@nanog.org Subject: Re: ISP customer assignments Organizations will be provided /48s or smaller, but given the current issues with routing /48's globally, I think you will find more organizations fighting for /32s or smaller... Most organizations will still be assigned a /48 (or whatever) from their ISP. Provider-aggregable addressing has no routing scalability problems. I can see between IPv4 and IPv6 is how much of a pain it is to type a 128 bit address... I have to agree, here. Moving between letters and numbers, and having to hit shift to use the colon wastes valuable keystrokes compared to the keypad. However, compare IPv6 vs IPv4-like numbering: 2001:db8:f1::1 81.93.35.12.241.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1 Did I type the right number of zeroes? Lee
RE: ISP customer assignments
Rick et al, I work at an ISP, and I know staff at several other ISPs, we are all trying to do this right. If a /56 makes sense and is supported by the IPv6 technology and we won't have issues supplying these to customers (technically speaking), then we will most likely do this or something similar. The issue is more of a nuanced issue. There seems to be a variance between It's OK to just give out a /64 to You better be thinking about giving out a /48. I can live in those boundaries and am most likely fine with either. I'm leaning toward a /56 for regular subscribers and a /48 only for business or large scale customers, and undecided on dial-up. How does this sound? This wasn't suppose to digress to this level of vitriol. - Brian -Original Message- From: Ricky Beam [mailto:jfb...@gmail.com] Sent: Monday, October 05, 2009 10:23 PM To: Joe Greco; robert.e.vanor...@frb.gov Cc: nanog@nanog.org Subject: Re: ISP customer assignments On Mon, 05 Oct 2009 20:14:01 -0400, Joe Greco jgr...@ns.sol.net wrote: Generally speaking, we shouldn't *want* end users to be provided with a single /64. The number of addresses is not the point. The idea of getting rid of the horribleness that is CIDR is the point. You underestimate the power of the marketing department and the bean counters. I assure you, residential ISPs are looking for schemes to give out as little address space as possible. The current revision of IPv6 introduces a way to nail down the boundary between network and host. This is fantastic, from an implementation point of view. It simplifies the design of silicon for forwarding engines, etc. And it's 150% Wrong Thinking(tm). IPv6 is classless - PERIOD. The instant some idiot wires /64 into silicon, we're right back to not being able to use x.x.x.0 and x.x.x.255. Addresses are 128-bits; you cannot make any assumptions about what people may or may not be doing with those bits. If I don't use SLAAC, then I'm not bound by it's lame rules. You don't do that. Or at least, you shouldn't do that. :-) We have a fairly reliable DNS system these days... And where did DNS get the name/number assignments? In my case, it's either been typed in by ME or automatically updated by DHCP. --Ricky
Re: ISP customer assignments
On Oct 6, 2009, at 7:29 AM, Lee Howard wrote: -Original Message- From: robert.e.vanor...@frb.gov [mailto:robert.e.vanor...@frb.gov] Sent: Monday, October 05, 2009 7:41 PM To: nanog@nanog.org Subject: Re: ISP customer assignments Organizations will be provided /48s or smaller, but given the current issues with routing /48's globally, I think you will find more organizations fighting for /32s or smaller... Most organizations will still be assigned a /48 (or whatever) from their ISP. Provider-aggregable addressing has no routing scalability problems. I can see between IPv4 and IPv6 is how much of a pain it is to type a 128 bit address... I have to agree, here. Moving between letters and numbers, and having to hit shift to use the colon wastes valuable keystrokes compared to the keypad. However, compare IPv6 vs IPv4-like numbering: 2001:db8:f1::1 81.93.35.12.241.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1 Did I type the right number of zeroes? I don't know, but, it's not 81.93.35.12... It's: 32.1.13.184.241.0.0.0.0.0.0.0.0.0.0.1 And that is the correct number of zeroes for 2001:db8:f1::1. Also, there's no reason the syntax couldn't be made 32.1.13.184.241..1 although that isn't the case today. However, I believe that 90.1 is supposed to be parsed equivalent to 90.0.0.1 and 90.5.1 is supposed to be treated as 90.5.0.1, so, 32.1.13.184.241.1 should also work for the above if you expanded todays IPv4 notation to accept IPv6 length addresses. Owen Lee
Re: ISP customer assignments
On Tue, 06 Oct 2009 09:34:28 PDT, Owen DeLong said: although that isn't the case today. However, I believe that 90.1 is supposed to be parsed equivalent to 90.0.0.1 and 90.5.1 is supposed to be treated as 90.5.0.1, so, 32.1.13.184.241.1 should also work for the above if you expanded todays IPv4 notation to accept IPv6 length addresses. So if you expand the notation like that, is 32.1.13.7 a 32 bit IPv4 address, or a 128 bit IPv6 address with lots of zeros between 13 and 7? They chose the : instead of overloading '.' for a *reason*... pgpckqTyuip4k.pgp Description: PGP signature
Re: ISP customer assignments
On Tue, 6 Oct 2009 09:25:44 -0500 Dan White dwh...@olp.net wrote: On 05/10/09 23:23 -0400, Ricky Beam wrote: You underestimate the power of the marketing department and the bean counters. I assure you, residential ISPs are looking for schemes to give out as little address space as possible. That has not been my (limited) experience. If you are aware of any ISPs which are not handing out a reasonable address space to customers, please call them out. Once one of them actually realises how much address space they've been given, and that giving more perceived value to a customer will win them the business, I think they will e.g. same price, same quota/bandwidth, one ISP giving you 64K more address space. I think customers will say, I fully understand what it's for, and I don't really know what I'll use it for .. but I'll have it if I ever need it. The current revision of IPv6 introduces a way to nail down the boundary between network and host. This is fantastic, from an implementation point of view. It simplifies the design of silicon for forwarding engines, etc. And it's 150% Wrong Thinking(tm). IPv6 is classless - PERIOD. The instant some idiot wires /64 into silicon, we're right back to not being able to use x.x.x.0 and x.x.x.255. Addresses are 128-bits; you cannot make any assumptions about what people may or may not be doing with those bits. If I don't use SLAAC, then I'm not bound by it's lame rules. I think it is both classless and classfull (although it's different enough that we probably should stop using loaded IPv4 terms ...) Forwarding is purely classless - the best route is the one with the longest matching prefix length, regardless of where that prefix length lands within the 128 bits. For 1/8th of the address space, it's classful. It's been shown that humans work best with simplicity, so introducing fixed operational (but not forwarding) boundaries between node, subnet and global prefixes makes IPv6 much more operationally simple than dealing with IPv4 classes, subnets or classless addressing. I think anybody who has dealt operationally with IPX, Appletalk, XNS, DECnet or even Ethernet with it's single OUI/Node ID boundary would agree. If the plan for the classful 1/8th ends up being wrong, the classless forwarding means that we don't have to deploy new routing code or hardware to change to a different addressing model, be it classless or something else. You don't do that. Or at least, you shouldn't do that. :-) We have a fairly reliable DNS system these days... The assumption that IPv6 addresses are harder has not been my experience. A server address of 2610:b8:5::1 is just as easy for me to remember as 67.217.144.1. Granted, auto configured addresses are much harder to remember. And where did DNS get the name/number assignments? In my case, it's either been typed in by ME or automatically updated by DHCP. Anything I put in DNS is a server/router, and gets a static address, just like with IPv4. -- Dan White BTC Broadband
Re: ISP customer assignments
unimaginably huge *classless* network. Yet, 2 hours into day one, a classful boundary has already been woven into it's DNA. Saying it's No bit patterns in a V6 address indicate total size of a network. v6 doesn't bring classful addressing back or get rid of CIDR.. v6 dispenses with something much older: common use of VLSM on the local LAN and sizing subnets based on the number of hosts. Instead a form of FLSM is recommended, a fixed standard subnet size of /64 that essentially all IPv6 networks use for the subnets that have hosts on them. This restores consistency to LAN addressing. In V4 there is a valid reason for choosing VLSM and sizing every subnet: IP addresses are scarce. V6 removes that scarcity problem. No more unanticipated growth necessitating an addressing re-design, or at least error-prone adjustment of netmasks on all hosts. No more hodgepodge of different netmask settings for different sized LANs. No more LAN address ranges starting or ending with a different trailing string of digits than other LANs. /64 is the standard. V6 leaves the operator able to pick something different, but in most cases it would be a very poor design practice, and ISPs should think long and hard before ignoring the standard and trying to issue a customer subnet a /128, instead of /48 or /56. However... none of the network protocol documents were ever able to prevent determined people from coming up with bad designs, or ignoring recommendations due to politics or preconceived notion(s); don't hold your breath on that one... -- -J
Re: ISP customer assignments
On Tue, 06 Oct 2009 17:40:40 -0400, Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org wrote: I think it is both classless and classfull (although it's different enough that we probably should stop using loaded IPv4 terms ...) It's _classless_. There's none of this Class A, B, C, D, or E nonsense. The word everyone is dancing around is, hierarchical. How the bits get divided up depends on what you want to do with it. SLAAC, in it's current form, requires a 64-bit prefix, but there are other ways to assign addresses that do not have that requirement. --Ricky
Re: ISP customer assignments
Brian Johnson wrote: From what I can tell from an ISP perspective, the design of IPv6 is for assignment of a /64 to an end user. Is this correct? Is this how it is currently being done? If not, where am I going wrong? The most common thing I see is /64 if the end user only needs one subnet, /56 if they need more than one. ~Seth
RE: ISP customer assignments
So a customer with a single PC hooked up to their broad-band connection would be given 2^64 addresses? I realize that this is future proofing, but OMG! That’s the IPv4 Internet^2 for a single device! Am I still seeing/reading/understanding this correctly? - Brian -Original Message- From: Seth Mattinen [mailto:se...@rollernet.us] Sent: Monday, October 05, 2009 10:38 AM To: nanog@nanog.org Subject: Re: ISP customer assignments Brian Johnson wrote: From what I can tell from an ISP perspective, the design of IPv6 is for assignment of a /64 to an end user. Is this correct? Is this how it is currently being done? If not, where am I going wrong? The most common thing I see is /64 if the end user only needs one subnet, /56 if they need more than one. ~Seth
Re: ISP customer assignments
On Oct 5, 2009, at 17:38, Seth Mattinen wrote: The most common thing I see is /64 if the end user only needs one subnet, /56 if they need more than one. Brrzt, wrong. Neither the end user nor you know the answer to that question! So the only sensible thing is to always give them a /56. (Actually, the IPv6 address architecture design was to give them a / 48. Think about it: We will run out of MAC addresses before we run out of those. But some people can't manage the cognitive dissonance coming from an address starving IPv4 world and then wasting all these 2^80 addresses. My parents, who grew up around WW2, were that way, too, and never could unlearn their saving habits. So the current wise thing is to allocate a /56, wasting only 2^72 addresses per customer. The only way back to a connected Internet.) Gruesse, Carsten
Re: ISP customer assignments
Yes, each and every network segment (especially multi-access ones) should be /64s. Regardless of the types of machines, speed of link, etc. It is an entirely different model of addressing, whose name just happens to start with IP ... /TJ On Mon, Oct 5, 2009 at 12:08 PM, Brian Johnson bjohn...@drtel.com wrote: So a customer with a single PC hooked up to their broad-band connection would be given 2^64 addresses? I realize that this is future proofing, but OMG! That’s the IPv4 Internet^2 for a single device! Am I still seeing/reading/understanding this correctly? - Brian -Original Message- From: Seth Mattinen [mailto:se...@rollernet.us] Sent: Monday, October 05, 2009 10:38 AM To: nanog@nanog.org Subject: Re: ISP customer assignments Brian Johnson wrote: From what I can tell from an ISP perspective, the design of IPv6 is for assignment of a /64 to an end user. Is this correct? Is this how it is currently being done? If not, where am I going wrong? The most common thing I see is /64 if the end user only needs one subnet, /56 if they need more than one. ~Seth -- /TJ
Re: ISP customer assignments
Carsten Bormann wrote: On Oct 5, 2009, at 17:38, Seth Mattinen wrote: The most common thing I see is /64 if the end user only needs one subnet, /56 if they need more than one. Brrzt, wrong. Neither the end user nor you know the answer to that question! So the only sensible thing is to always give them a /56. I'm just relating what's common *right now*, not what I would do personally. ~Seth
Re: ISP customer assignments
On Mon, Oct 5, 2009 at 11:27 AM, Brian Johnson bjohn...@drtel.com wrote: From what I can tell from an ISP perspective, the design of IPv6 is for assignment of a /64 to an end user. Is this correct? Is this how it is currently being done? If not, where am I going wrong? No. A /64 is one *subnet*. Essentially the standard, static size for any Ethernet LAN. For a customer, the following values are more appropriate: /128 - connecting exactly one computer. Probably only useful for your dynamic dialup customers. Any always-on or static-IP customer should probably have a CIDR block. /48 - current ARIN/IETF recommendation for a downstream customer connecting more than one computer unless that customer is large enough to need more than 65k LANs. /56 - in some folks opinion, slightly more sane than assigning a 65k subnets and bazillions of addresses to a home hobbyist with half a dozen PC's. /60 - the smallest amount you should allocate to a downstream customer with more than one computer. Anything smaller will cost you extra management overhead from not matching the nibble boundary for RDNS delegation, handling multiple routes when the customer grows, not matching the standard /64 subnet size and a myriad other obscure issues. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: ISP customer assignments
more-or-less. Can I suggest you read: http://en.wikipedia.org/wiki/IPv6 Think of ipv6 not as 128 bits of address space, but more as a addressing system with a globally unique host part and 2^64 possible subnets. In this respect it's substantially different to ipv4. And after reading Wikipedia, follow it up with ARIN's http://www.getipv6.info wiki site. --Michael Dillon
RE: ISP customer assignments
What would be wrong with using a /64 for a customer who only has a local network? Most home users won't understand what a subnet is. - Brian -Original Message- From: wher...@gmail.com [mailto:wher...@gmail.com] On Behalf Of William Herrin Sent: Monday, October 05, 2009 11:58 AM To: Brian Johnson Cc: nanog@nanog.org Subject: Re: ISP customer assignments On Mon, Oct 5, 2009 at 11:27 AM, Brian Johnson bjohn...@drtel.com wrote: From what I can tell from an ISP perspective, the design of IPv6 is for assignment of a /64 to an end user. Is this correct? Is this how it is currently being done? If not, where am I going wrong? No. A /64 is one *subnet*. Essentially the standard, static size for any Ethernet LAN. For a customer, the following values are more appropriate: /128 - connecting exactly one computer. Probably only useful for your dynamic dialup customers. Any always-on or static-IP customer should probably have a CIDR block. /48 - current ARIN/IETF recommendation for a downstream customer connecting more than one computer unless that customer is large enough to need more than 65k LANs. /56 - in some folks opinion, slightly more sane than assigning a 65k subnets and bazillions of addresses to a home hobbyist with half a dozen PC's. /60 - the smallest amount you should allocate to a downstream customer with more than one computer. Anything smaller will cost you extra management overhead from not matching the nibble boundary for RDNS delegation, handling multiple routes when the customer grows, not matching the standard /64 subnet size and a myriad other obscure issues. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
