Re: Foundry CLI manual?
It would be a good idea to have a bug database that accessible to paying support customers. Joe McGuckin ViaNet Communications j...@via.net 650-207-0372 cell 650-213-1302 office 650-969-2124 fax On Jan 23, 2010, at 8:23 AM, Richard A Steenbergen wrote: On Sat, Jan 23, 2010 at 10:51:57AM -0500, David Hubbard wrote: Anyone have the Foundry/Brocade CLI reference PDF they could send me? Brocade feels you should have a support contract to have a list of commands the hardware you purchased offers and I'm having difficulty with a oc12 pos module. Ironically enough the manuals themselves are accessable without a login, but the list of manuals is not. You fail to mention which product you're interested in, so I'm going to take a stab and hope that it's something current with a pos card like an MLX/XMR. If you're still rocking an old B2P622, I'd say you're in need of far more help than any manual can provide. :) http://www.foundrynet.com/services/documentation/xmr_user/current/NetIron_04100_ConfigGuide.pdf http://www.foundrynet.com/services/documentation/xmr_diag/current/NetIronXMR-MLX_04100_DiagnosticRef.pdf -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: DURZ published in root - you ready?
On 01/24/10 18:53, Mark Andrews wrote: In message202705b1001241834l5b1911bat97ee2130f632f...@mail.gmail.com, Jorge Amodio writes: Good point, tomorrow/today we'll start seeing what gets broken and hopefully why. Regards. Jorge I don't expect to see much until the last root server (J) switches over. DNS implemententations are remarkably robust at routing around percieved damage. Week of 2010-05-03: J starts to serve DURZ There's some evidence within the traffic to the authoritative servers for the now-signed berkeley.edu zone that answers from the authoritative servers are not being received by certain queriers. These queriers, who are setting DO (and of course EDNS0) in their queries, are retrying the same queries until they reach the one sacrificial lamb server that is set to give out minimal answers and limit EDNS0 responses to 512 bytes (thereby frequently triggering failover to TCP for those minimal answers that still exceed 512 bytes). It will be interesting to see how traffic patterns to the various root servers evolve as more servers get the DURZ. Also, I got my first apparently DNSSEC-related your server is attacking me notice. It was little more than a log snippet that indicated that a UCB authoritative server was perpetrating a big bomb attack on a system behind this firewall. Big bomb is a notification from Netgear firewalls and CPE routers. Not sure how much activity the abuse contacts for the various rootops netblocks get, but you'll probably see more. michael
Re: Using /126 for IPv6 router links
On 24/01/2010 02:44, Larry Sheldon wrote: On 1/23/2010 8:24 PM, Owen DeLong wrote: 64 bits is enough networks that if each network was an almond MM, you would be able to fill all of the great lakes with MMs before you ran out of /64s. Did somebody once say something like that about Class C addresses? No. There are only 2,097,152 Class C networks. Assuming all MMs are spheroids of uniform oblate nature, radius major axis=6mm, minor axis=3mm. Volume is (4/3)Pi (Major^2) Minor (http://en.wikipedia.org/wiki/Spheroid#Volume) They will be poured into a great lake of your choice, and we will assume random close packing (agitation mechanisms are probably best discussed off-list) and a (generous, but the article insists) void fraction of 32%. (http://en.wikipedia.org/wiki/Random_close_pack) Volume of mm = 0.452cm^3, occupies 0.665cm^3. Lake Erie is 484km^3 http://www.epa.gov/glnpo/factsheet.html 1 km^3 = 1,000,000,000,000,000 cm^3 484,000,000,000,000,000 * 0.665 = 321,860,000,000,000,000 mms needed to fill this lake. There are 4,294,967,296 /64s in my own /32 allocation. If we only ever use 2000::/3 on the internet, I make that 2,305,843,009,213,693,952 /64s. This is enough to fill over seven Lake Eries. The total amount of ipv6 address space is exponentially larger still - I have just looked at 2000::/3 in these maths. THE IPv6 ADDRESS SPACE IS VERY, VERY, VERY BIG. ** Can we please now just go ahead and roll out some ipv6 services ? ** Thanks Andy
Re: Using /126 for IPv6 router links
On Sat, Jan 23, 2010 at 4:52 AM, Mathias Seiler mathias.sei...@mironet.ch wrote: Hi In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard. I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong. So what do you think? Good? Bad? Ugly? /127 ? ;) Cheers Mathias Seiler MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel T +41 61 201 30 90, F +41 61 201 30 99 mathias.sei...@mironet.ch www.mironet.ch As I mentioned in my lightning talk at the last NANOG, we reserved a /64 for each PtP link, but configured it as the first /126 out of the /64. That gives us the most flexibility for expanding to the full /64 later if necessary, but prevents us from being victim of the classic v6 neighbor discovery attack that you're prone to if you configure the entire /64 on the link. All someone out on the 'net needs to do is scan up through your address space on the link as quickly as possible, sending single packets at all the non-existent addresses on the link, and watch as your router CPU starts to churn keeping track of all the neighbor discovery messages, state table updates, and incomplete age-outs. With the link configured as a /126, there's a very small limit to the number of neighbor discovery messages, and the amount of state table that needs to be maintained and updated for each PtP link. It seemed like a reasonable approach for us--but there's more than one way to skin this particular cat. Hope this helps! Matt
Re: Using /126 for IPv6 router links
On Mon, Jan 25, 2010 at 09:12:49AM +, Andy Davidson wrote: There are 4,294,967,296 /64s in my own /32 allocation. If we only ever use 2000::/3 on the internet, I make that 2,305,843,009,213,693,952 /64s. This is enough to fill over seven Lake Eries. The total amount of ipv6 address space is exponentially larger still - I have just looked at 2000::/3 in these maths. THE IPv6 ADDRESS SPACE IS VERY, VERY, VERY BIG. Don't get carried away with all of that IPv6 is huge math, it quickly deteriorates when you start digging into it. Auto-configuration reduces it from 340282366920938463463374607431768211456 to 18446744073709551616 (that's 0.05% of the original 128 bit space). Now as an end user you might get anything ranging from a /56 to a /64, that's only between 1 - 256 IPs, barely a significant increase at all if you were to actually use a /64 for each routed IP rather than as each routed subnet. As a small network you might get a /48, so that even if you gave out /64s to everyone it would be only 16 bits of space for you (the equivalent of getting a class B back in IPv4 land), something like a 8-16 bit improvement over what a similar sized network would have gotten in IPv4. As a bigger ISP you might get a /32, but it's the same thing, only 16 bits of space when you have to give out /48s. All we've really done is buy ourselves an 8 to 16 bit improvement at every level of allocation space (and a lot of prefix bloat for when we start using more than 2000::/3), which is a FAR cry from the 2^128 omg big number, we can give every molecule an IPv6 address math of the popular imagination. :) -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Using /31 for router links
On 23/01/10 19:52, Michael Sokolov wrote: Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org wrote: As for ATM... The part that totally baffles me about the use of ATM on xDSL lines is that I have never, ever, ever seen an xDSL line carrying more than one ATM VC. OK, there may be someone out there who has set up a configuration like that just for fun, but 99.999% of all ATM'd xDSL lines out there carry a single PVC at 0*35 or 0*38. It's common practice down here in Italy to have more than one VC. One is used to carry data and the other one is used for VoIP, so that you don't have to do QoS on the data part. Ciao ! -- Massimiliano Stucchi BrianTel Srl stuc...@briantel.com Tel (+39) 039 9669921 | Fax (+39) 02 44417204 I-23807, Merate (Lecco), via Mameli 6 MS16801-RIPE
RE: Using /126 for IPv6 router links
Good Morning! -Original Message- From: Richard A Steenbergen [mailto:r...@e-gerbil.net] Sent: Monday, January 25, 2010 05:45 To: Andy Davidson Cc: nanog@nanog.org Subject: Re: Using /126 for IPv6 router links On Mon, Jan 25, 2010 at 09:12:49AM +, Andy Davidson wrote: There are 4,294,967,296 /64s in my own /32 allocation. If we only ever use 2000::/3 on the internet, I make that 2,305,843,009,213,693,952 /64s. This is enough to fill over seven Lake Eries. The total amount of ipv6 address space is exponentially larger still - I have just looked at 2000::/3 in these maths. THE IPv6 ADDRESS SPACE IS VERY, VERY, VERY BIG. Don't get carried away with all of that IPv6 is huge math, it quickly deteriorates when you start digging into it. Auto-configuration reduces it from 340282366920938463463374607431768211456 to 18446744073709551616 (that's 0.05% of the original 128 bit space). Now as an end user you might get anything ranging from a /56 to a /64, that's only between 1 - 256 IPs, barely a significant increase at all if you were to actually use a /64 for each routed IP rather than as each routed subnet. As a small network you might get a /48, so that even if you gave out /64s to everyone it would be only 16 bits of space for you (the equivalent of getting a class B back in IPv4 land), something like a 8-16 bit improvement over what a similar sized network would have gotten in IPv4. As a bigger ISP you might get a /32, but it's the same thing, only 16 bits of space when you have to give out /48s. All we've really done is buy ourselves an 8 to 16 bit improvement at every level of allocation space (and a lot of prefix bloat for when we start using more than 2000::/3), which is a FAR cry from the 2^128 omg big number, we can give every molecule an IPv6 address math of the popular imagination. :) While I agree with parts of what you are saying - that using the simple 2^128 math can be misleading, let's be clear on a few things: *) 2^61 is still very, very big. That is the number of IPv6 network segments available within 2000::/3. *) An end-user should get something between a /48 and a /56, _maybe_ as low as a /60 ... hopefully never a /64. Really. **) Let's call the /48s enterprise assignments, and the /56s home assignments ... ? **) And your /56 to /64 is NOT 1-256 IPs, it is 1-256 segments. **) And, using the expected /48-/56, the numbers are really 256-64k subnets. **) Each segment supporting as many hosts as you want it to. Probably nowhere near 2^64, but that isn't the point :). *) _Any_ ISP gets a /32 by default, a bigger ISP can readily get more. So, actually, we have 'bought' ourselves much more space. *) The standard registry allocation is a /12. So within the /3 we have 512 of those. Note: We currently have 5 RIRs. *) A /12 yields 20 bits of /32s. So within any given /12, we have ~1M ISPs. *) The standard ISP /32 can support 64K Enterprises or 16.7M Homes. **) Oh, and if you need more = just ask. *) Even allowing for inefficiency / room to grow / summarization - I think we are good for quite some time. *) And this is just the first /3. Note: All we've really done is buy ourselves an 8 to 16 bit improvement at every level of allocation space *) And you don't think 8-16 bits _AT EVERY LEVEL_ is a bit deal?? **) Remembering that the original address space was 'only' 32bits. **) I guess only supporting 256-64k more registries, each of which can support 256-64k more ISPs, each of which can support 256-64k more customers just isn't that useful to you? *) Additionally - the number of IPs per segment, which is not the same as the number of hosts per segment, is much vaster. The quite common IPv4 /24 being analogous to an IPv6 /64 ... /TJ PS - We also get much more multicast space, Which Is Nice(TM).
Re: Using /126 for IPv6 router links
Ok let's summarize: /64: + Sticks to the way IPv6 was designed (64 bits host part) + Probability of renumbering very low + simpler for ACLs and the like + rDNS on a bit boundary You can give your peers funny names, like 2001:db8::dead:beef ;) - Prone to attacks (scans, router CPU load) - Waste of addresses - Peer address needs to be known, impossible to guess with 2^64 addresses /126 + Only 4 addresses possible (memorable, not so error-prone at configuration-time and while debugging) + Not prone to scan-like attacks - Not on a bit boundary, so more complicated for ACLs and … - … rDNS - Perhaps need to renumber into /64 some time. - No 64 bits for hosts /127 Like /126 but there's an RFC not recommending it and an RFC (draft) which revises that non-recommendation. On 25 Jan 2010, at 10:14, Matthew Petach wrote: On Sat, Jan 23, 2010 at 4:52 AM, Mathias Seiler mathias.sei...@mironet.ch wrote: Hi In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard. I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong. So what do you think? Good? Bad? Ugly? /127 ? ;) Cheers Mathias Seiler MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel T +41 61 201 30 90, F +41 61 201 30 99 mathias.sei...@mironet.ch www.mironet.ch As I mentioned in my lightning talk at the last NANOG, we reserved a /64 for each PtP link, but configured it as the first /126 out of the /64. That gives us the most flexibility for expanding to the full /64 later if necessary, but prevents us from being victim of the classic v6 neighbor discovery attack that you're prone to if you configure the entire /64 on the link. I think I will go this way. Since we've got the usual /32 assignment I have plenty of /64 to waste. If I continue assigning a /48 to every customer I can set apart a /64 for each PtP link and still have room to grow for a very long time (I'm not taking into account the assignment of IPv6 addresses to high amounts of MMs so far ;) ) This way the configuration and addressing plan is simple and understandable to anyone. All someone out on the 'net needs to do is scan up through your address space on the link as quickly as possible, sending single packets at all the non-existent addresses on the link, and watch as your router CPU starts to churn keeping track of all the neighbor discovery messages, state table updates, and incomplete age-outs. Well I could filter that in hardware with an interface ACL but a /126 seems much easier to maintain. With the link configured as a /126, there's a very small limit to the number of neighbor discovery messages, and the amount of state table that needs to be maintained and updated for each PtP link. It seemed like a reasonable approach for us--but there's more than one way to skin this particular cat. Hope this helps! Yes it does. Thanks! Mathias Seiler MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel T +41 61 201 30 90, F +41 61 201 30 99 mathias.sei...@mironet.ch www.mironet.ch smime.p7s Description: S/MIME cryptographic signature
RE: Using /126 for IPv6 router links
From: Mathias Seiler [mailto:mathias.sei...@mironet.ch] Subject: Re: Using /126 for IPv6 router links Ok let's summarize: /64: + Sticks to the way IPv6 was designed (64 bits host part) + Probability of renumbering very low + simpler for ACLs and the like + rDNS on a bit boundary You can give your peers funny names, like 2001:db8::dead:beef ;) - Prone to attacks (scans, router CPU load) - Waste of addresses - Peer address needs to be known, impossible to guess with 2^64 addresses /126 + Only 4 addresses possible (memorable, not so error-prone at configuration-time and while debugging) + Not prone to scan-like attacks - Not on a bit boundary, so more complicated for ACLs and ... - ... rDNS - Perhaps need to renumber into /64 some time. - No 64 bits for hosts You're forgetting Matthew Petach's suggestion- reserve/assign a /64 for each PtP link, but only configure the first /126 (or whatever /126 you need to get an amusing peer address) on the link. + Sticks to the way IPv6 was designed (64 bits host part- even if it isn't all configured) + Probability of renumbering very low + simpler for ACLs and the like + rDNS on a bit boundary + Only 4 addresses possible (memorable, not so error-prone at configuration-time and while debugging) + Not prone to scan-like attacks + Easy to renumber into a /64 if you need to - Waste of addresses Seems to be a fairly good compromise, unless there's something I missed. ~Matt
L-Root Maintenance 2010-01-27 1800 UTC - 2000 UTC
Hi As part of staged, incremental deployment of DNSSEC in the root zone L-Root will begin serving a Deliberately Unvalidatable Root Zone (DURZ) after the completion of its scheduled maintenance at 2010-01-27 1800 UTC - 2000 UTC Please contact L-Root NOC via n...@dns.icann.org or T: +1.310.301.5817 if you have any questions. Please contact with roots...@icann.org if you have any questions regarding DNSSEC Deployment at root zone. Regards Joe Abley / Mehmet Akcin / Dave Knight ICANN DNS Ops / L-ROOT
Re: Using /126 for IPv6 router links
In a message written on Mon, Jan 25, 2010 at 05:14:06PM +0100, Mathias Seiler wrote: Ok let's summarize: /64: + Sticks to the way IPv6 was designed (64 bits host part) + Probability of renumbering very low + simpler for ACLs and the like + rDNS on a bit boundary You can give your peers funny names, like 2001:db8::dead:beef ;) - Prone to attacks (scans, router CPU load) - Waste of addresses - Peer address needs to be known, impossible to guess with 2^64 addresses /112: + 65535 possible addresses, can use a standardized subnet for everything from a 2 router point to point, to a six address vrrp to vrrp dual router static setup, and beyond. Becomes the universal edge interface when the far end is routers not hosts. + rDNS bit boundary++, since it falls on a :. + Limits the effects of scan-like attacks. + Can set aside 1 /64 of /112's for, well, forever. /126 + Only 4 addresses possible (memorable, not so error-prone at configuration-time and while debugging) + Not prone to scan-like attacks - Not on a bit boundary, so more complicated for ACLs and ? - ? rDNS - Perhaps need to renumber into /64 some time. - No 64 bits for hosts /127 Like /126 but there's an RFC not recommending it and an RFC (draft) which revises that non-recommendation. On 25 Jan 2010, at 10:14, Matthew Petach wrote: On Sat, Jan 23, 2010 at 4:52 AM, Mathias Seiler mathias.sei...@mironet.ch wrote: Hi In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard. I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong. So what do you think? Good? Bad? Ugly? /127 ? ;) Cheers Mathias Seiler MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel T +41 61 201 30 90, F +41 61 201 30 99 mathias.sei...@mironet.ch www.mironet.ch As I mentioned in my lightning talk at the last NANOG, we reserved a /64 for each PtP link, but configured it as the first /126 out of the /64. That gives us the most flexibility for expanding to the full /64 later if necessary, but prevents us from being victim of the classic v6 neighbor discovery attack that you're prone to if you configure the entire /64 on the link. I think I will go this way. Since we've got the usual /32 assignment I have plenty of /64 to waste. If I continue assigning a /48 to every customer I can set apart a /64 for each PtP link and still have room to grow for a very long time (I'm not taking into account the assignment of IPv6 addresses to high amounts of MMs so far ;) ) This way the configuration and addressing plan is simple and understandable to anyone. All someone out on the 'net needs to do is scan up through your address space on the link as quickly as possible, sending single packets at all the non-existent addresses on the link, and watch as your router CPU starts to churn keeping track of all the neighbor discovery messages, state table updates, and incomplete age-outs. Well I could filter that in hardware with an interface ACL but a /126 seems much easier to maintain. With the link configured as a /126, there's a very small limit to the number of neighbor discovery messages, and the amount of state table that needs to be maintained and updated for each PtP link. It seemed like a reasonable approach for us--but there's more than one way to skin this particular cat. Hope this helps! Yes it does. Thanks! Mathias Seiler MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel T +41 61 201 30 90, F +41 61 201 30 99 mathias.sei...@mironet.ch www.mironet.ch -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpJhfssxAejV.pgp Description: PGP signature
Re: Using /126 for IPv6 router links
On Mon, Jan 25, 2010 at 09:10:11AM -0500, TJ wrote: While I agree with parts of what you are saying - that using the simple 2^128 math can be misleading, let's be clear on a few things: *) 2^61 is still very, very big. That is the number of IPv6 network segments available within 2000::/3. *) An end-user should get something between a /48 and a /56, _maybe_ as low as a /60 ... hopefully never a /64. Really. **) Let's call the /48s enterprise assignments, and the /56s home assignments ... ? **) And your /56 to /64 is NOT 1-256 IPs, it is 1-256 segments. It is if we are to follow the always use a /64 as a single IP guidelines. Not that I'm encouraging this, I'm just saying this is what we're told to do with the space. I for one have this little protocol called DHCP that does IP assignments along with a bunch of other things that I need anyways, so I'm more than happy to take a single /64 for house as a single lan segment (well, never minding the fact that my house has a /48). **) And, using the expected /48-/56, the numbers are really 256-64k subnets. ... Note: All we've really done is buy ourselves an 8 to 16 bit improvement at every level of allocation space *) And you don't think 8-16 bits _AT EVERY LEVEL_ is a bit deal?? I'm not saying that 8-16 bits isn't an improvement, but it's a far cry from the bazillions of numbers everyone makes IPv6 out to be. By the time you figure in the overhead of autoconfiguration, restrictive initial deployments, and the now that the space is much bigger, we should be reallocating bigger blocks logic at every layer of redistribution, that is what you're left with. So far all we've really done with v6 is created a flashback to the days when every end user could get a /24 just by asking, every enterprise could get a /16 just by asking, and every big network could get a /8 just by asking, just bit shifted a little bit. That's all well and good, but it isn't a bazillion. :) -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
RE: Using /126 for IPv6 router links
-Original Message- From: Richard A Steenbergen [mailto:r...@e-gerbil.net] Sent: Monday, January 25, 2010 12:08 To: TJ Cc: nanog@nanog.org Subject: Re: Using /126 for IPv6 router links On Mon, Jan 25, 2010 at 09:10:11AM -0500, TJ wrote: While I agree with parts of what you are saying - that using the simple 2^128 math can be misleading, let's be clear on a few things: *) 2^61 is still very, very big. That is the number of IPv6 network segments available within 2000::/3. *) An end-user should get something between a /48 and a /56, _maybe_ as low as a /60 ... hopefully never a /64. Really. **) Let's call the /48s enterprise assignments, and the /56s home assignments ... ? **) And your /56 to /64 is NOT 1-256 IPs, it is 1-256 segments. It is if we are to follow the always use a /64 as a single IP guidelines. Not that I'm encouraging this, I'm just saying this is what we're told to do with the space. I for one have this little protocol called DHCP that does IP assignments along with a bunch of other things that I need anyways, so I'm more than happy to take a single /64 for house as a single lan segment (well, never minding the fact that my house has a /48). Interesting. I have never seen anyone say always use a /64 as a single IP ... perhaps you mean as an IP segment or link? You are assigned a /64 if it is known that you only need one segment, which yields as many IPs as you want (18BillionBillion or so) - and the reality is that a home user should get a /56 and an enterprise should get a /48, at the very least - some would say a /48 per site. **) And, using the expected /48-/56, the numbers are really 256-64k subnets. ... Note: All we've really done is buy ourselves an 8 to 16 bit improvement at every level of allocation space *) And you don't think 8-16 bits _AT EVERY LEVEL_ is a bit deal?? I'm not saying that 8-16 bits isn't an improvement, but it's a far cry from the bazillions of numbers everyone makes IPv6 out to be. By the time you figure in the overhead of autoconfiguration, restrictive initial deployments, and the now that the space is much bigger, we should be reallocating bigger blocks logic at every layer of redistribution, that is what you're left with. So far all we've really done with v6 is created a flashback to the days when every end user could get a /24 just by asking, every enterprise could get a /16 just by asking, and every big network could get a /8 just by asking, just bit shifted a little bit. That's all well and good, but it isn't a bazillion. :) There are some similarities between IPv6 and old classful addressing, but the bit-boundaries chosen were intentionally made big and specifically factoring in the then-ongoing scarcity (Ye olde Class B exhaustion). The scale of the difference *is* the difference. I am not quite sure what a bazillion is, but when we get into the Billion Billion range I think that is close enough! :) /TJ
Re: Using /126 for IPv6 router links
On Mon, Jan 25, 2010 at 1:01 PM, TJ trej...@gmail.com wrote: -Original Message- From: Richard A Steenbergen [mailto:r...@e-gerbil.net] Sent: Monday, January 25, 2010 12:08 To: TJ Cc: nanog@nanog.org Subject: Re: Using /126 for IPv6 router links On Mon, Jan 25, 2010 at 09:10:11AM -0500, TJ wrote: While I agree with parts of what you are saying - that using the simple 2^128 math can be misleading, let's be clear on a few things: *) 2^61 is still very, very big. That is the number of IPv6 network segments available within 2000::/3. *) An end-user should get something between a /48 and a /56, _maybe_ as low as a /60 ... hopefully never a /64. Really. **) Let's call the /48s enterprise assignments, and the /56s home assignments ... ? **) And your /56 to /64 is NOT 1-256 IPs, it is 1-256 segments. It is if we are to follow the always use a /64 as a single IP guidelines. Not that I'm encouraging this, I'm just saying this is what we're told to do with the space. I for one have this little protocol called DHCP that does IP assignments along with a bunch of other things that I need anyways, so I'm more than happy to take a single /64 for house as a single lan segment (well, never minding the fact that my house has a /48). Interesting. I have never seen anyone say always use a /64 as a single IP ... perhaps you mean as an IP segment or link? You are assigned a /64 if it is known that you only need one segment, which yields as many IPs as you want (18BillionBillion or so) - and the reality is that a home user should get a /56 and an enterprise should get a /48, at the very least - some would say a /48 per site. **) And, using the expected /48-/56, the numbers are really 256-64k subnets. ... Note: All we've really done is buy ourselves an 8 to 16 bit improvement at every level of allocation space *) And you don't think 8-16 bits _AT EVERY LEVEL_ is a bit deal?? I'm not saying that 8-16 bits isn't an improvement, but it's a far cry from the bazillions of numbers everyone makes IPv6 out to be. By the time you figure in the overhead of autoconfiguration, restrictive initial deployments, and the now that the space is much bigger, we should be reallocating bigger blocks logic at every layer of redistribution, that is what you're left with. So far all we've really done with v6 is created a flashback to the days when every end user could get a /24 just by asking, every enterprise could get a /16 just by asking, and every big network could get a /8 just by asking, just bit shifted a little bit. That's all well and good, but it isn't a bazillion. :) There are some similarities between IPv6 and old classful addressing, but the bit-boundaries chosen were intentionally made big and specifically factoring in the then-ongoing scarcity (Ye olde Class B exhaustion). The scale of the difference *is* the difference. I am not quite sure what a bazillion is, but when we get into the Billion Billion range I think that is close enough! :) /TJ 2^128 is a very big number. However, from a network engineering perspective, IPv6 is really only 64bits of network address space. 2^64 is still a very big number. An end-user assignment /48 is really only 2^16 networks. That's not very big once you start planning a human-friendly repeatable number plan. An ISP allocation is /32, which is only 2^16 /48s. Again, not that big. Once you start planning a practical address plan, IPv6 isn't as big as everybody keeps saying... -- Tim: Sent from Brooklyn, NY, United States
Re: Using /126 for IPv6 router links
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Our numbering plan is this: 1) Autoconfigured hosts possible? /64 2) Autoconfigured hosts not-possible, we control both sides? /126 3) Autoconfigured hosts not-possible, we DON'T control both sides? /64 4) Loopback? /128 Within our /48 we've carved it into (4) /50s. * First, Infrastructure. This makes ACLs cake. ** Within this /50 are smaller allocations for /126s and /128s and /64s. * Second, User Subnets (16k /64s available) ** All non-infrastructure subnets are assigned from this pool. * Third, Reserved. * Fourth, Reserved. We believe this plan gives us the most flexibility in the future. We made these choices based upon what works the best for us and our tools and not to conserve addresses. Using a single /64 ACL to permit/deny traffic to all ptp at the border was extremely attractive, etc. - -- Ryan M. Harden, BS, KC9IHX Office: 217-265-5192 CITES - Network Engineering Cell: 217-689-1363 2130 Digital Computer Lab Fax:217-244-7089 1304 W. Springfield email: harde...@illinois.edu Urbana, IL 61801 University of Illinois at Urbana/Champaign - AS38 University of Illinois - ICCN - AS40387 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAktd77sACgkQtuPckBBbXbpI1QCcCHBU8XcxqTAKDy4SbElfpH7L VlYAoMkhFKHPeIAXb3vepXYDLdgVAmFA =H3uZ -END PGP SIGNATURE-
Re: Using /126 for IPv6 router links
On Mon, Jan 25, 2010 at 2:23 PM, Ryan Harden harde...@uiuc.edu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Our numbering plan is this: 1) Autoconfigured hosts possible? /64 2) Autoconfigured hosts not-possible, we control both sides? /126 3) Autoconfigured hosts not-possible, we DON'T control both sides? /64 4) Loopback? /128 Within our /48 we've carved it into (4) /50s. * First, Infrastructure. This makes ACLs cake. ** Within this /50 are smaller allocations for /126s and /128s and /64s. * Second, User Subnets (16k /64s available) ** All non-infrastructure subnets are assigned from this pool. * Third, Reserved. * Fourth, Reserved. We believe this plan gives us the most flexibility in the future. We made these choices based upon what works the best for us and our tools and not to conserve addresses. Using a single /64 ACL to permit/deny traffic to all ptp at the border was extremely attractive, etc. - -- This is what we have planned: 2620::xx00::/41 AS-NETx-2620-0-xx00 2620::xx00::/44 Infrastructure 2620::xx01::/48 Pop1 Infrastructure 2620::xx01:::/64Router Loopback (2^64 x /128) 2620::xx01:0001::/64Transit net (2^48 x /112) 2620::xx01:0002::/64Server Switch management 2620::xx01:0003::/64Access Switch management 2620::xx0f::/48 Pop16Infrastructure 2620::xx10::/44 Sparse Reservation 2620::xx20::/44 Sparse Reservation 2620::xx30::/44 Pop1 Services 2620::xx30::/48 Cust1 Services 2620::xx30:0001::/64VLAN_1 2620::xx30:4094::/64VLAN_4094 2620::xx31::/48 Cust2 Services 2620::xx31:0001::/64VLAN_1 2620::xx31:4094::/64VLAN_4094 2620::xx32::/48 Cust3 Services 2620::xx31:0001::/64VLAN_1 2620::xx31:4094::/64VLAN_4094 2620::xx32::/48 Cust4 Services 2620::xx31:0001::/64VLAN_1 2620::xx31:4094::/64VLAN_4094 2620::xx32::/48 RES-PD-32 (4096 x /60) 2620::xx3f::/48 RES-PD-3f (4096 x /60) 2620::xx40::/44 Pop2 Services 2620::xx50::/44 Pop3 Services 2620::xx60::/44 Pop4 services 2620::xx70::/44 Pop5 Services This is a multiple campus network, customers are all internal. I have had to squeeze Residential PDs down to /60s to make it fit. One Pop is really 3 sites in one. This has had to be massaged into one Pop also. To be safe, I'm thinking of adjusting loopbacks and ptp to be /64s. I'm reasonably happy with the plan, but it doesn't seem to have that much room to grow. -- Tim: Sent from Brooklyn, NY, United States
RE: Using /126 for IPv6 router links
-Original Message- From: Tim Durack [mailto:tdur...@gmail.com] Sent: Monday, January 25, 2010 14:03 To: TJ Cc: nanog@nanog.org Subject: Re: Using /126 for IPv6 router links snip 2^128 is a very big number. However, from a network engineering perspective, IPv6 is really only 64bits of network address space. 2^64 is still a very big number. An end-user assignment /48 is really only 2^16 networks. That's not very big once you start planning a human-friendly repeatable number plan. An ISP allocation is /32, which is only 2^16 /48s. Again, not that big. Once you start planning a practical address plan, IPv6 isn't as big as everybody keeps saying... I didn't realize human friendly was even a nominal design consideration, especially as different humans have different tolerances for defining friendly :) I (continue to) maintain that: *) 2^16 is still a pretty good size number, even allowing for aggregation / summarization. *) If you are large enough that this isn't true - you should (have) request(ed) more, naturally - each bit doubles your space ... /TJ
Re: Using /126 for IPv6 router links
From: TJ trej...@gmail.com Date: Mon, 25 Jan 2010 15:15:55 -0500 -Original Message- From: Tim Durack [mailto:tdur...@gmail.com] Sent: Monday, January 25, 2010 14:03 To: TJ Cc: nanog@nanog.org Subject: Re: Using /126 for IPv6 router links snip 2^128 is a very big number. However, from a network engineering perspective, IPv6 is really only 64bits of network address space. 2^64 is still a very big number. An end-user assignment /48 is really only 2^16 networks. That's not very big once you start planning a human-friendly repeatable number plan. An ISP allocation is /32, which is only 2^16 /48s. Again, not that big. Once you start planning a practical address plan, IPv6 isn't as big as everybody keeps saying... I didn't realize human friendly was even a nominal design consideration, especially as different humans have different tolerances for defining friendly :) It was absolutely an issue. The excellent A6 proposal was killed because it was not human friendly. Very computer friendly, but people were not too happy about dealing with it. It was, in most ways, vastly superior to , but a real pain to try to deal with by hand. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Using /126 for IPv6 router links
On 26/01/2010, at 8:50 AM, Tim Durack wrote: This is what we have planned: 2620::xx00::/41 AS-NETx-2620-0-xx00 2620::xx00::/44 Infrastructure 2620::xx01::/48 Pop1 Infrastructure 2620::xx01:::/64Router Loopback (2^64 x /128) 2620::xx01:0001::/64Transit net (2^48 x /112) 2620::xx01:0002::/64Server Switch management 2620::xx01:0003::/64Access Switch management 2620::xx0f::/48 Pop16Infrastructure Why do you force POP infrastructure to be a /48? That allows you only 16 POPs which is pretty restrictive IMO. Why not simply take say 4 /48s and sparsely allocate /56s to each POP and then grow the /56s if you require more networks at each POP. You only have a need for 4 /64s at each POP right now, so the 256 that a /56 gives you sounds like more than enough, and up to 1024 POPs (assuming you don't outgrow any of the /56s). Also I'd strongly recommend not stuffing decimal numbers in to a hexadecimal field. It might seem like a good idea right now to make the learning curve easier, but it's going to make stuff annoying long term. You don't have anything in IPv4 that's big enough to indicate the VLAN number and you've lived just fine for years, so forcing it to be decimal like that isn't really needed. You're much better off giving your staff the tools to translate between the two, rather than burn networks in order to fudge some kind of human readability out of it and sacrificing your address space to get it. % printf %04x\n 4095 0fff % printf %d\n 0x0fff 4095 -- Nathan Ward
Re: Using /126 for IPv6 router links
On Jan 25, 2010, at 8:14 AM, Mathias Seiler wrote: Ok let's summarize: /64: + Sticks to the way IPv6 was designed (64 bits host part) + Probability of renumbering very low + simpler for ACLs and the like + rDNS on a bit boundary You can give your peers funny names, like 2001:db8::dead:beef ;) - Prone to attacks (scans, router CPU load) Unless of course you just block nonexistent addresses in the /64 at each end. - Waste of addresses - Peer address needs to be known, impossible to guess with 2^64 addresses Most of us use ::1 for the assigning side and ::2 for the non-assigning side of the connection. On multipoints, such as exchanges, the popular alternative is to use either the BCD of the ASN or the hex of the ASN for your first connection and something like ::1:AS:N for subsequent connections. /126 + Only 4 addresses possible (memorable, not so error-prone at configuration-time and while debugging) + Not prone to scan-like attacks Equally prone to scan like attacks, but, no ACL required to reduce vulnerability. - Not on a bit boundary, so more complicated for ACLs and … - … rDNS - Perhaps need to renumber into /64 some time. - No 64 bits for hosts /127 Like /126 but there's an RFC not recommending it and an RFC (draft) which revises that non-recommendation. On 25 Jan 2010, at 10:14, Matthew Petach wrote: On Sat, Jan 23, 2010 at 4:52 AM, Mathias Seiler mathias.sei...@mironet.ch wrote: Hi In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard. I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong. So what do you think? Good? Bad? Ugly? /127 ? ;) Cheers Mathias Seiler MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel T +41 61 201 30 90, F +41 61 201 30 99 mathias.sei...@mironet.ch www.mironet.ch As I mentioned in my lightning talk at the last NANOG, we reserved a /64 for each PtP link, but configured it as the first /126 out of the /64. That gives us the most flexibility for expanding to the full /64 later if necessary, but prevents us from being victim of the classic v6 neighbor discovery attack that you're prone to if you configure the entire /64 on the link. I think I will go this way. Since we've got the usual /32 assignment I have plenty of /64 to waste. If I continue assigning a /48 to every customer I can set apart a /64 for each PtP link and still have room to grow for a very long time (I'm not taking into account the assignment of IPv6 addresses to high amounts of MMs so far ;) ) This way the configuration and addressing plan is simple and understandable to anyone. All someone out on the 'net needs to do is scan up through your address space on the link as quickly as possible, sending single packets at all the non-existent addresses on the link, and watch as your router CPU starts to churn keeping track of all the neighbor discovery messages, state table updates, and incomplete age-outs. Well I could filter that in hardware with an interface ACL but a /126 seems much easier to maintain. With the link configured as a /126, there's a very small limit to the number of neighbor discovery messages, and the amount of state table that needs to be maintained and updated for each PtP link. It seemed like a reasonable approach for us--but there's more than one way to skin this particular cat. Hope this helps! Yes it does. Thanks! Mathias Seiler MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel T +41 61 201 30 90, F +41 61 201 30 99 mathias.sei...@mironet.ch www.mironet.ch
Re: Using /126 for IPv6 router links
On Jan 25, 2010, at 9:07 AM, Richard A Steenbergen wrote: On Mon, Jan 25, 2010 at 09:10:11AM -0500, TJ wrote: While I agree with parts of what you are saying - that using the simple 2^128 math can be misleading, let's be clear on a few things: *) 2^61 is still very, very big. That is the number of IPv6 network segments available within 2000::/3. *) An end-user should get something between a /48 and a /56, _maybe_ as low as a /60 ... hopefully never a /64. Really. **) Let's call the /48s enterprise assignments, and the /56s home assignments ... ? **) And your /56 to /64 is NOT 1-256 IPs, it is 1-256 segments. It is if we are to follow the always use a /64 as a single IP guidelines. Not that I'm encouraging this, I'm just saying this is what we're told to do with the space. I for one have this little protocol called DHCP that does IP assignments along with a bunch of other things that I need anyways, so I'm more than happy to take a single /64 for house as a single lan segment (well, never minding the fact that my house has a /48). I'm not sure where you're getting that. I've always heard use a /64 as a single segment, not as a single host. **) And, using the expected /48-/56, the numbers are really 256-64k subnets. ... Note: All we've really done is buy ourselves an 8 to 16 bit improvement at every level of allocation space *) And you don't think 8-16 bits _AT EVERY LEVEL_ is a bit deal?? I'm not saying that 8-16 bits isn't an improvement, but it's a far cry from the bazillions of numbers everyone makes IPv6 out to be. By the time you figure in the overhead of autoconfiguration, restrictive initial deployments, and the now that the space is much bigger, we should be reallocating bigger blocks logic at every layer of redistribution, that is what you're left with. So far all we've really done with v6 is created a flashback to the days when every end user could get a /24 just by asking, every enterprise could get a /16 just by asking, and every big network could get a /8 just by asking, just bit shifted a little bit. That's all well and good, but it isn't a bazillion. :) Yeah, but, that wasn't inherently bad, and, in this version of the flashback, we actually have enough addresses to do it and still have 7/8ths of the address space held in reserve. The biggest problems with the flashback days were: 1. Not enough addresses to do that on an ongoing basis. 2. No accountability or reclamation ability. Problem 1 is solved by the larger number of bits at each level of the hierarchy (/12 instead of /8 to the RIRs, /32 instead of /[12-20] to ISPs, /48 (or /56) to end users instead of /24, and, no worries about trying to pack 8 hosts into a /28 and dreading the day they become 15 hosts. Problem 2 is solved by the RIR system and their respective RSAs. As much as people grumble about paying RIR fees for their addresses, there is definite value to the community from the RIR system. So, to sum up... In the current /3 IANA is using, there are enough delegations for 512 /12s to be given to RIRs. In each /12, there's 1024k /32s. Even if we figure that 1/4 of all ISPs need a /28, that's support for a lot of ISPs in each RIR. (65536 if ALL ISPs needed a /28). In each /32, an ISP can handle 65,536 customers (so a /28 supports 256k customers all at /48). A residential ISP can probably stretch that /48 quite a bit further by giving each residential customer a /56 unless they specifically ask for a /48. In a /32, there are 16,777,216 /56s. That still gives the household room for 256 separate /64 networks, which, admittedly would be sufficient even for my relatively more intense than average network at home. (yes, I have a /48, but, I could easily live within a /56 if such were available when I requested my space.) Owen
Re: Enhancing automation with network growth
I want to thank everyone who responded on, and off-list to this thread. I've garnered valuable information that ranges within the technical, business applicability, to 'common-sense' arenas. There is a lot of information that I have to go over now, and a few select pieces of software that I'm going to test immediately. One more question, if I may... My original post was completely concerned on automating the process of spinning traffic throughput graphs. Are there any software packages that stand out that have the ability to differentiate throughput between v4/v6, as opposed to the aggregate of the interface? (I will continue reading docs of all recommendations, but this may expedite the process a bit). Steve
Re: Using /126 for IPv6 router links
On Jan 25, 2010, at 10:50 AM, Larry Sheldon wrote: On 1/25/2010 4:45 AM, Richard A Steenbergen wrote: On Mon, Jan 25, 2010 at 09:12:49AM +, Andy Davidson wrote: There are 4,294,967,296 /64s in my own /32 allocation. If we only ever use 2000::/3 on the internet, I make that 2,305,843,009,213,693,952 /64s. This is enough to fill over seven Lake Eries. The total amount of ipv6 address space is exponentially larger still - I have just looked at 2000::/3 in these maths. THE IPv6 ADDRESS SPACE IS VERY, VERY, VERY BIG. Don't get carried away with all of that IPv6 is huge math, it quickly deteriorates when you start digging into it. Auto-configuration reduces it from 340282366920938463463374607431768211456 to 18446744073709551616 (that's 0.05% of the original 128 bit space). Now as an end user you might get anything ranging from a /56 to a /64, that's only between 1 - 256 IPs, barely a significant increase at all if you were to actually use a /64 for each routed IP rather than as each routed subnet. As a small network you might get a /48, so that even if you gave out /64s to everyone it would be only 16 bits of space for you (the equivalent of getting a class B back in IPv4 land), something like a 8-16 bit improvement over what a similar sized network would have gotten in IPv4. As a bigger ISP you might get a /32, but it's the same thing, only 16 bits of space when you have to give out /48s. All we've really done is buy ourselves an 8 to 16 bit improvement at every level of allocation space (and a lot of prefix bloat for when we start using more than 2000::/3), which is a FAR cry from the 2^128 omg big number, we can give every molecule an IPv6 address math of the popular imagination. :) And it does not account for the factor that I was trying to shine a light on--the it-is-infinitely-huge is at risk of failing due to inventions we can not conceive of. Who knew, in the 1940's that every person would be assigned as many as five or more telephone numbers (exaggeration? In this house, occupied by two people there are 4 addressable PSTN devices, only one of which leaves the house if one of us does, and there are 6 devices that share an address but could easily have individual addresses, and would if we were using one of the VOIP services). Sure, but, to put this in perspective, the entire 10-digit NANP could be numbered in a single /64 with several copies of NANP worth of addresses left over... NANP: 1,000,000,000 addresses. /64: 18,446,744,073,709,551,616 addresses An RIR /12 contains enough end-user /48s to hold NANP and then some: NANP: 1,000,000,000 addresses /12: 68,719,476,736 /48s (End User Sites) /12: 1,048,576 /32s (ISPs) (there are currently less than 50,000 registered phone companies) Who knew in the 1980's that refrigerator's would need IP addresses? (We should not have been surprised, Coke machines did.) As to refrigerators, probably all the appliances in a house can share a handful of subnets. A /56 per household provides for MANY appliance networks as well as separate networks for just about everything else you can imagine. Worst case, even if all households end up with /48s the address space is still sufficient. And for all the concern about IPv4 exhaustion, what would have happened if the people who fought fiercely against RFC 1918 had won the day? IPv6 deployment would be a lot further along and we wouldn't have spent nearly so much money overcoming the pitfalls and problems created by NAT. We wouldn't now have to spend even more money trying to get past the errant NAT=Security thinking. Yes the numbers in IPv6 are huge, no doubt about it. But I say, to say impossible to exhaust is a fools errand. Somebody will find a way to exhaust the pool, just to be contrary, if for no currently recognized legitimate reason. No, they're not impossible to exhaust, just pretty difficult. However, If we see exhaustion coming too soon in this /3, we can always apply a more conservative numbering policy to the next /3. (And still have 5 /3s left to innovate and try other alternatives). Owen
Re: Using /126 for IPv6 router links
2^128 is a very big number. However, from a network engineering perspective, IPv6 is really only 64bits of network address space. 2^64 is still a very big number. An end-user assignment /48 is really only 2^16 networks. That's not very big once you start planning a human-friendly repeatable number plan. An end-user MINIMUM assignment (assignment for a single site) is a /48. (with the possible exception of /56s for residential customers that don't ask for a /48). I have worked in lots of different enterprises and have yet to see one that had more than 65,536 networks in a single site. I'm not saying they don't exist, but, I will say that they are extremely rare. Multiple sites are a different issue. There are still enough /48s to issue one per site. An ISP allocation is /32, which is only 2^16 /48s. Again, not that big. That's just the starting minimum. Many ISPs have already gotten much larger IPv6 allocations. Once you start planning a practical address plan, IPv6 isn't as big as everybody keeps saying... It's more than big enough for any deployment I've seen so far with plenty of room to spare. Owen
Re: Using /126 for IPv6 router links
On Mon, Jan 25, 2010 at 8:01 PM, Owen DeLong o...@delong.com wrote: 2^128 is a very big number. However, from a network engineering perspective, IPv6 is really only 64bits of network address space. 2^64 is still a very big number. An end-user assignment /48 is really only 2^16 networks. That's not very big once you start planning a human-friendly repeatable number plan. An end-user MINIMUM assignment (assignment for a single site) is a /48. (with the possible exception of /56s for residential customers that don't ask for a /48). I have worked in lots of different enterprises and have yet to see one that had more than 65,536 networks in a single site. I'm not saying they don't exist, but, I will say that they are extremely rare. Multiple sites are a different issue. There are still enough /48s to issue one per site. Networks per site isn't the issue. /48s per organization is my concern. Guidelines on assignment size for end-user sites aren't clear. It comes down to the discretion of ARIN. That's why I like pp 106. It takes some of the guess-work/fudge-factor out of assignments. An ISP allocation is /32, which is only 2^16 /48s. Again, not that big. That's just the starting minimum. Many ISPs have already gotten much larger IPv6 allocations. Understood. Again, the problem for me is medium/large end-user sites that have to justify an assignment to a RIR that doesn't have clear guidelines on multiple /48s. Once you start planning a practical address plan, IPv6 isn't as big as everybody keeps saying... It's more than big enough for any deployment I've seen so far with plenty of room to spare. Owen -- Tim: Sent from Brooklyn, NY, United States
Re: Using /126 for IPv6 router links
On Mon, Jan 25, 2010 at 7:33 PM, Owen DeLong o...@delong.com wrote: On Jan 25, 2010, at 8:14 AM, Mathias Seiler wrote: Ok let's summarize: /64: + Sticks to the way IPv6 was designed (64 bits host part) + Probability of renumbering very low + simpler for ACLs and the like + rDNS on a bit boundary You can give your peers funny names, like 2001:db8::dead:beef ;) - Prone to attacks (scans, router CPU load) Unless of course you just block nonexistent addresses in the /64 at each end. uhm, how sensible is this? Use s^64 address, block all but the first 2 I'm confused by the goal of using a /64 on a ptp link that never will have more than 2 addresses on it? I get that 'years ago' understanding what a /30 or a /31 is was 'hard' for people but seriously, this is 2010... - Waste of addresses - Peer address needs to be known, impossible to guess with 2^64 addresses Most of us use ::1 for the assigning side and ::2 for the non-assigning side of the connection. On multipoints, such as exchanges, the popular alternative is to use either the BCD of the ASN or the hex of the ASN for your first connection and something like ::1:AS:N for subsequent connections. multipoint exchanges are out of scope of the discission, or so I had counted earlier. /126 + Only 4 addresses possible (memorable, not so error-prone at configuration-time and while debugging) + Not prone to scan-like attacks Equally prone to scan like attacks, but, no ACL required to reduce vulnerability. how so? How do you reduce this without an acl or some sort somewhere that needs to be maintained? (I think I'm asking for some config snippets with explanations, perhaps it's documented somewhere already even? :) ) -Chris - Not on a bit boundary, so more complicated for ACLs and … - … rDNS - Perhaps need to renumber into /64 some time. - No 64 bits for hosts /127 Like /126 but there's an RFC not recommending it and an RFC (draft) which revises that non-recommendation. On 25 Jan 2010, at 10:14, Matthew Petach wrote: On Sat, Jan 23, 2010 at 4:52 AM, Mathias Seiler mathias.sei...@mironet.ch wrote: Hi In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard. I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong. So what do you think? Good? Bad? Ugly? /127 ? ;) Cheers Mathias Seiler MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel T +41 61 201 30 90, F +41 61 201 30 99 mathias.sei...@mironet.ch www.mironet.ch As I mentioned in my lightning talk at the last NANOG, we reserved a /64 for each PtP link, but configured it as the first /126 out of the /64. That gives us the most flexibility for expanding to the full /64 later if necessary, but prevents us from being victim of the classic v6 neighbor discovery attack that you're prone to if you configure the entire /64 on the link. I think I will go this way. Since we've got the usual /32 assignment I have plenty of /64 to waste. If I continue assigning a /48 to every customer I can set apart a /64 for each PtP link and still have room to grow for a very long time (I'm not taking into account the assignment of IPv6 addresses to high amounts of MMs so far ;) ) This way the configuration and addressing plan is simple and understandable to anyone. All someone out on the 'net needs to do is scan up through your address space on the link as quickly as possible, sending single packets at all the non-existent addresses on the link, and watch as your router CPU starts to churn keeping track of all the neighbor discovery messages, state table updates, and incomplete age-outs. Well I could filter that in hardware with an interface ACL but a /126 seems much easier to maintain. With the link configured as a /126, there's a very small limit to the number of neighbor discovery messages, and the amount of state table that needs to be maintained and updated for each PtP link. It seemed like a reasonable approach for us--but there's more than one way to skin this particular cat. Hope this helps! Yes it does. Thanks! Mathias Seiler MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel T +41 61 201 30 90, F +41 61 201 30 99 mathias.sei...@mironet.ch www.mironet.ch
Re: Using /126 for IPv6 router links
On Mon, Jan 25, 2010 at 8:01 PM, Owen DeLong o...@delong.com wrote: Once you start planning a practical address plan, IPv6 isn't as big as everybody keeps saying... It's more than big enough for any deployment I've seen so far with plenty of room to spare. Oh good! so the us-DoD's /10 request is getting filled when? -Chris
Re: Using /126 for IPv6 router links
On Mon, Jan 25, 2010 at 9:26 PM, Tim Durack tdur...@gmail.com wrote: An ISP allocation is /32, which is only 2^16 /48s. Again, not that big. That's just the starting minimum. Many ISPs have already gotten much larger IPv6 allocations. Understood. Again, the problem for me is medium/large end-user sites that have to justify an assignment to a RIR that doesn't have clear guidelines on multiple /48s. some of what you're saying (tim) here is that you could: (one of these) 1) go to all your remote-office ISP's and get a /48 from each 2) go to *RIR's and get /something to cover the number of remote sites you have in their region(s) 3) keep on keepin' on until something better comes along? I think for each you have this at least as pitfalls: 1) o no simple way to aggregate internally the 48's or subsets of the 48's o no simple way to define 'internal' vs 'external' at the address level for your remote/main sites o renumbering concerns when/if you decide to change ISP's at remote offices o multihoming concerns with PA space in v6-land 2) o justification in light of 'unclear' policies for an address block of the right size. NOTE:I don't think the policies is unclear, but that could be my misreading of the policies. o will your remote-office's ISP's accept the /48's per site? (vz/vzb is a standout example here) o will your remote-office's have full reachability to the parts of the network they need access to? (remote ISP's filtering at/above the /48 boundary) For the Enterprise still used to v4-land ipv6 isn't a win yet... for an ISP it's relatively[0] simple. -Chris 0: address interfaces, turn up protocols, add 'security' assign customers /48's...(yes fight bugs/problems/'why is there a colon in my ip address? (what if you do have 200 offices in the US which aren't connected on a private network today?)
RE: Using /31 for router links
We use 5 PVCs for the IP video and one for Internet. Not as uncommon as you think. Frank -Original Message- From: Michael Sokolov [mailto:msoko...@ivan.harhan.org] Sent: Saturday, January 23, 2010 12:53 PM To: nanog@nanog.org Subject: Re: Using /31 for router links Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org wrote: What about NAT, ATM cell tax, unnecessary addressing fields in PTP protocols (including your beloved HDLC), SSAP, DSAP fields not being big enough in 802.2 necessitating SNAP, IPX directly over 802.3, AAL1 through AAL4, PPPoE dumbell MTUs and MSS hacks? Some of those are far worse sins in my opinion. snip As for ATM... The part that totally baffles me about the use of ATM on xDSL lines is that I have never, ever, ever seen an xDSL line carrying more than one ATM VC. OK, there may be someone out there who has set up a configuration like that just for fun, but 99.999% of all ATM'd xDSL lines out there carry a single PVC at 0*35 or 0*38. So what then is the point of running ATM?!?! All the hyped benefits of ATM (a little cell can squeeze in the middle of a big packet without waiting for it to finish, yadda yadda yadda) are contingent upon having more than one VPI/VCI going across the interface! If every single non-idle cell going across that ATM interface is 0*35 or 0*38, the interface will never carry anything other a direct succession of cells making up an AAL5 packet, strictly in sequence and without interruption. So what's the point of ATM then? Why chop that packet up into cells only to transmit those cells in direct sequence one after another? Why not simply send that same packet in plain HDLC over the same copper pairs/fiber? OK, the backhaul network upstream of the DSLAM may be ATM and that one does have many VCs, so ATM *might* be of use there, but even in that case why not do FRF.8 in the DSLAM and keep the ATM strictly on the backhaul, sending HDLC down the copper pairs? off the soapbox for the moment MS
Re: Using /126 for IPv6 router links
On Mon, 25 Jan 2010 14:50:35 -0500 Tim Durack tdur...@gmail.com wrote: On Mon, Jan 25, 2010 at 2:23 PM, Ryan Harden harde...@uiuc.edu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Our numbering plan is this: 1) Autoconfigured hosts possible? /64 2) Autoconfigured hosts not-possible, we control both sides? /126 3) Autoconfigured hosts not-possible, we DON'T control both sides? /64 4) Loopback? /128 Within our /48 we've carved it into (4) /50s. * First, Infrastructure. This makes ACLs cake. ** Within this /50 are smaller allocations for /126s and /128s and /64s. * Second, User Subnets (16k /64s available) ** All non-infrastructure subnets are assigned from this pool. * Third, Reserved. * Fourth, Reserved. We believe this plan gives us the most flexibility in the future. We made these choices based upon what works the best for us and our tools and not to conserve addresses. Using a single /64 ACL to permit/deny traffic to all ptp at the border was extremely attractive, etc. - -- This is what we have planned: 2620::xx00::/41 AS-NETx-2620-0-xx00 2620::xx00::/44 Infrastructure 2620::xx01::/48 Pop1 Infrastructure 2620::xx01:::/64Router Loopback (2^64 x /128) 2620::xx01:0001::/64Transit net (2^48 x /112) 2620::xx01:0002::/64Server Switch management 2620::xx01:0003::/64Access Switch management 2620::xx0f::/48 Pop16Infrastructure 2620::xx10::/44 Sparse Reservation 2620::xx20::/44 Sparse Reservation 2620::xx30::/44 Pop1 Services 2620::xx30::/48 Cust1 Services 2620::xx30:0001::/64VLAN_1 2620::xx30:4094::/64VLAN_4094 2620::xx31::/48 Cust2 Services 2620::xx31:0001::/64VLAN_1 2620::xx31:4094::/64VLAN_4094 2620::xx32::/48 Cust3 Services 2620::xx31:0001::/64VLAN_1 2620::xx31:4094::/64VLAN_4094 2620::xx32::/48 Cust4 Services 2620::xx31:0001::/64VLAN_1 2620::xx31:4094::/64VLAN_4094 2620::xx32::/48 RES-PD-32 (4096 x /60) 2620::xx3f::/48 RES-PD-3f (4096 x /60) 2620::xx40::/44 Pop2 Services 2620::xx50::/44 Pop3 Services 2620::xx60::/44 Pop4 services 2620::xx70::/44 Pop5 Services This is a multiple campus network, customers are all internal. I have had to squeeze Residential PDs down to /60s to make it fit. One Pop is really 3 sites in one. This has had to be massaged into one Pop also. To be safe, I'm thinking of adjusting loopbacks and ptp to be /64s. I'm reasonably happy with the plan, but it doesn't seem to have that much room to grow. If you haven't already, you may wish to have a read of RFC3531 - A Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block. It suggests a method of subnet assignment such that you're not stuck with your initial boundary estimations. -- Tim: Sent from Brooklyn, NY, United States
Re: Using /126 for IPv6 router links
On Mon, 25 Jan 2010 15:15:55 -0500 TJ trej...@gmail.com wrote: -Original Message- From: Tim Durack [mailto:tdur...@gmail.com] Sent: Monday, January 25, 2010 14:03 To: TJ Cc: nanog@nanog.org Subject: Re: Using /126 for IPv6 router links snip 2^128 is a very big number. However, from a network engineering perspective, IPv6 is really only 64bits of network address space. 2^64 is still a very big number. An end-user assignment /48 is really only 2^16 networks. That's not very big once you start planning a human-friendly repeatable number plan. An ISP allocation is /32, which is only 2^16 /48s. Again, not that big. Once you start planning a practical address plan, IPv6 isn't as big as everybody keeps saying... I didn't realize human friendly was even a nominal design consideration, especially as different humans have different tolerances for defining friendly :) This from people who can probably do decimal to binary conversion and back again for IPv4 subnetting in their head and are proud of it. Surely IPv6 hex to binary and back again can be the new party trick? :-) I (continue to) maintain that: *) 2^16 is still a pretty good size number, even allowing for aggregation / summarization. *) If you are large enough that this isn't true - you should (have) request(ed) more, naturally - each bit doubles your space ... /TJ
Re: Using /126 for IPv6 router links
On 1/25/2010 20:06, Mark Smith wrote: This from people who can probably do decimal to binary conversion and back again for IPv4 subnetting in their head and are proud of it. Surely IPv6 hex to binary and back again can be the new party trick? :-) Hehe. Decimal - binary in your head? I don't even bother except if it's some well known magic #s. Hex - binary though is super simple since unlike decimal, each digit translates exactly into a nybble. You just have to know the binary from 0 - 15, 16 simple four-bit patterns, and it's a piece of cake. You can give me hex numbers and and I'll rattle off binary all day, or vica-versa. Octal is similarly easy, but would result in some long IPv6 addresses. :-) smime.p7s Description: S/MIME Cryptographic Signature
