Choice of network space when numbering interfaces with IPv6
SO I have been turning up v6 with multiple providers now and notice that some choose /64 for numbering interfaces but one I came across use a /126. A /126 is awfully large (for interface numbering) and I am curious if there is some rationale behind using a /126 instead of a /64. Zaid
On 2010-10-15 21:26, Zaid Ali wrote:
SO I have been turning up v6 with multiple providers now and notice that some choose /64 for numbering interfaces but one I came across use a /126. A /126 is awfully large (for interface numbering) and I am curious if there is some rationale behind using a /126 instead of a /64.
You mean to say that a /126 is 'small' actually as it is only 2^(128-126) = 2^2 = 4 IP addresses while a /64 is...... For this discussion, please go through the archives. In short: Personal preference of operators involved. Greets, Jeroen
http://www.google.com/search?q=nanog+126+64 would be a good place to start... (And I'm guessing you mean that /64 is "awfully large", not /126) Scott. On Fri, Oct 15, 2010 at 12:26 PM, Zaid Ali <zaid@zaidali.com> wrote:
SO I have been turning up v6 with multiple providers now and notice that some choose /64 for numbering interfaces but one I came across use a /126. A /126 is awfully large (for interface numbering) and I am curious if there is some rationale behind using a /126 instead of a /64.
Zaid
On 15/10/2010 20:26, Zaid Ali wrote:
SO I have been turning up v6 with multiple providers now and notice that some choose /64 for numbering interfaces but one I came across use a /126. A /126 is awfully large (for interface numbering) and I am curious if there is some rationale behind using a /126 instead of a /64.
There are 4 general choices of netmask for ipv6 point to point interface numbering schemes: /64: the default ipv4 subnet. many people feel that this is a waste of addressing space. others feel that there is so much ipv6 address space out there that it's simpler to keep all interfaces on /64. /112: /112 is 16-bit aligned, which means that it's easy to read because 16 bits implies that the last 4 octets are link-specific. Also, your entire PoP point-to-point addressing scheme can be held within a single /64, which means good address conservation /126: this is the same as we use in ipv4: it's less easy to read, as the link-specific digits are not octet-aligned. Your entire PoP point-to-point addressing scheme can be held within a single /64, which means good address conservation /127: this is used on POS links where there is no link-layer address resolution protocol available (like ARP/ND) and consequently you can end up with unknown traffic looping between each side if you're not careful. None of these is the right or the wrong approach, unless you're using POS/STM. Otherwise all of them have their merits and demerits. Nick
Bahh had my head turned around and brain fried on a Friday. I was more curious about /64 vs /126 from management perspective. Thanks everyone for answering offline as well, I got my questions answered. Zaid On 10/15/10 12:26 PM, "Zaid Ali" <zaid@zaidali.com> wrote:
SO I have been turning up v6 with multiple providers now and notice that some choose /64 for numbering interfaces but one I came across use a /126. A /126 is awfully large (for interface numbering) and I am curious if there is some rationale behind using a /126 instead of a /64.
Zaid
Hi, On Fri, 15 Oct 2010 12:26:13 -0700 Zaid Ali <zaid@zaidali.com> wrote:
SO I have been turning up v6 with multiple providers now and notice that some choose /64 for numbering interfaces but one I came across use a /126. A /126 is awfully large (for interface numbering) and I am curious if there is some rationale behind using a /126 instead of a /64.
If you're not going to follow the IPv6 Addressing Architecture, which says /64s for everything, then the prefix length decision is pretty much arbitrary - there is nothing that special about /112s, /126s, /127s or /128s (or /120s or /80s) - they all break something in the existing IPv6 RFCs so once you've passed that threshold then you're really only choosing your poison. If you're going to go down that latter path, I'd suggest reserving a /64 for each link, and then using a longer prefix length out of that /64 when you configure the addressing, to make it easier if you decided to change back to /64s at a later time. Regards, Mark.
but then, can't we use ip unumbered on p2p links on cisco? ----- Original Message ----- From: "Mark Smith" <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> To: "Zaid Ali" <zaid@zaidali.com> Cc: "NANOG list" <nanog@nanog.org> Sent: Saturday, 16 October, 2010 10:21:03 AM Subject: Re: Choice of network space when numbering interfaces with IPv6 Hi, On Fri, 15 Oct 2010 12:26:13 -0700 Zaid Ali <zaid@zaidali.com> wrote:
SO I have been turning up v6 with multiple providers now and notice that some choose /64 for numbering interfaces but one I came across use a /126. A /126 is awfully large (for interface numbering) and I am curious if there is some rationale behind using a /126 instead of a /64.
If you're not going to follow the IPv6 Addressing Architecture, which says /64s for everything, then the prefix length decision is pretty much arbitrary - there is nothing that special about /112s, /126s, /127s or /128s (or /120s or /80s) - they all break something in the existing IPv6 RFCs so once you've passed that threshold then you're really only choosing your poison. If you're going to go down that latter path, I'd suggest reserving a /64 for each link, and then using a longer prefix length out of that /64 when you configure the addressing, to make it easier if you decided to change back to /64s at a later time. Regards, Mark.
Date: Sat, 16 Oct 2010 08:51:03 +1030 From: Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org>
Hi,
On Fri, 15 Oct 2010 12:26:13 -0700 Zaid Ali <zaid@zaidali.com> wrote:
SO I have been turning up v6 with multiple providers now and notice that some choose /64 for numbering interfaces but one I came across use a /126. A /126 is awfully large (for interface numbering) and I am curious if there is some rationale behind using a /126 instead of a /64.
If you're not going to follow the IPv6 Addressing Architecture, which says /64s for everything, then the prefix length decision is pretty much arbitrary - there is nothing that special about /112s, /126s, /127s or /128s (or /120s or /80s) - they all break something in the existing IPv6 RFCs so once you've passed that threshold then you're really only choosing your poison. If you're going to go down that latter path, I'd suggest reserving a /64 for each link, and then using a longer prefix length out of that /64 when you configure the addressing, to make it easier if you decided to change back to /64s at a later time.
If you listen to the NANOG "debate" on IPv6 on P2P links, you will discover that the participants (Igor of Yahoo and Rob Seastrom of Affilias) agreed that the proper way to do this was to allocate a /64 for the link but to configure it as a /127. This was to avoid ping-pong DOS attacks. I believe that the session has already been cited, but see Igor's presentation at: http://nanog.org/meetings/nanog48/presentations/Tuesday/Gashinsky_LinkNumb_N... -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
On Sat, 16 Oct 2010 12:31:22 +0100 Randy Bush <randy@psg.com> wrote:
http://www.ietf.org/internet-drafts/draft-ietf-6man-prefixlen-p2p-00.txt
Drafts are drafts, and nothing more, aren't they?
Since we are on the topic of IPv6. I'd like to know if anyone has books/articles they recommend on fully understanding IPv6 adoption in the work place. I will need to contact ARIN shortly to request a v6 block. I'm assuming I would be asking for a /64 being an ISP. But I'd like to read up as much as possible before requesting the block.... I think our approach will be to use dual-stack on the routers and let the clients themselves handle how they want to use IPv6... Ultimately, it is up to them, their network, and their applications on how to use v6... Thanks guys!
On Oct 16, 2010, at 8:36 AM, Brandon Kim wrote:
Since we are on the topic of IPv6. I'd like to know if anyone has books/articles they recommend on fully understanding IPv6 adoption in the work place. I will need to contact ARIN shortly to request a v6 block.
I'm assuming I would be asking for a /64 being an ISP. But I'd like to read up as much as possible before requesting the block....
No, as an ISP, you should get at least a /32. A /64 is a single subnet in IPv6.
I think our approach will be to use dual-stack on the routers and let the clients themselves handle how they want to use IPv6...
Seems reasonable. FWIW, you should plan for assigning clients a /48 per end-site.
Ultimately, it is up to them, their network, and their applications on how to use v6...
Yep. Owen
Joel's widget number 2 On Oct 16, 2010, at 8:36, Brandon Kim <brandon.kim@brandontek.com> wrote:
Since we are on the topic of IPv6. I'd like to know if anyone has books/articles they recommend on fully understanding IPv6 adoption in the work place. I will need to contact ARIN shortly to request a v6 block.
I'm assuming I would be asking for a /64 being an ISP. But I'd like to read up as much as possible before requesting the block....
An ISP requesting an assignment would typically request a /32 For policy, I'd read the ARIN nrpm's section on v6 assignment. https://www.arin.net/policy/nrpm.html#six I'd also get a book, for background, something like: http://www.amazon.com/Running-IPv6-Iljitsch-van-Beijnum/dp/1590595270/ref=sr_1_3?ie=UTF8&qid=1287244118&sr=8-3#reader_1590595270 Then move on to the Internet which as with most things is where the most cuurent if not helpful information resides.
I think our approach will be to use dual-stack on the routers and let the clients themselves handle how they want to use IPv6...
Ultimately, it is up to them, their network, and their applications on how to use v6...
Thanks guys!
On Oct 16, 2010, at 10:56 PM, Joel Jaeggli wrote:
Then move on to the Internet which as with most things is where the most cuurent if not helpful information resides.
Eric Vyncke's IPv6 security book is definitely worthwhile, as well, in combination with Schudel & Smith's infrastructure security book (the latter isn't IPv6-specific, but is the best book out there on infrastructure security): <http://www.ciscopress.com/bookstore/product.asp?isbn=1587055945> <http://www.ciscopress.com/bookstore/product.asp?isbn=1587053365> ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Sell your computer and buy a guitar.
Thanks everyone who responded. This list is such a valuable wealth of information. Apparently I was wrong about the /64 as that should be /32 so thanks for that correction.... Thanks again especially on a Saturday weekend!
From: rdobbins@arbor.net To: nanog@nanog.org Date: Sat, 16 Oct 2010 16:09:43 +0000 Subject: Re: Definitive Guide to IPv6 adoption
On Oct 16, 2010, at 10:56 PM, Joel Jaeggli wrote:
Then move on to the Internet which as with most things is where the most cuurent if not helpful information resides.
Eric Vyncke's IPv6 security book is definitely worthwhile, as well, in combination with Schudel & Smith's infrastructure security book (the latter isn't IPv6-specific, but is the best book out there on infrastructure security):
<http://www.ciscopress.com/bookstore/product.asp?isbn=1587055945>
<http://www.ciscopress.com/bookstore/product.asp?isbn=1587053365>
----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Sell your computer and buy a guitar.
You give a /64 to the end users (home/soho), and /48 to multi homed organization (or bigger orgs that use more than one network internally) and get a /32 if you are an ISP. See also the discussion about what to use in p2p links. ----- Original Message ----- From: "Brandon Kim" <brandon.kim@brandontek.com> To: nanog@nanog.org Sent: Sunday, 17 October, 2010 8:58:57 AM Subject: RE: Definitive Guide to IPv6 adoption Thanks everyone who responded. This list is such a valuable wealth of information. Apparently I was wrong about the /64 as that should be /32 so thanks for that correction.... Thanks again especially on a Saturday weekend!
From: rdobbins@arbor.net To: nanog@nanog.org Date: Sat, 16 Oct 2010 16:09:43 +0000 Subject: Re: Definitive Guide to IPv6 adoption
On Oct 16, 2010, at 10:56 PM, Joel Jaeggli wrote:
Then move on to the Internet which as with most things is where the most cuurent if not helpful information resides.
Eric Vyncke's IPv6 security book is definitely worthwhile, as well, in combination with Schudel & Smith's infrastructure security book (the latter isn't IPv6-specific, but is the best book out there on infrastructure security):
<http://www.ciscopress.com/bookstore/product.asp?isbn=1587055945>
<http://www.ciscopress.com/bookstore/product.asp?isbn=1587053365>
----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Sell your computer and buy a guitar.
On Oct 16, 2010, at 5:22 PM, Franck Martin wrote:
You give a /64 to the end users (home/soho), and /48 to multi homed organization (or bigger orgs that use more than one network internally) and get a /32 if you are an ISP.
Please DON'T do that. End users (home/soho) should get at least a /56 and ideally a /48. The standards and the RIR policies both allow for end-users/sites to get /48s. If you are an ISP, you get AT LEAST a /32.
See also the discussion about what to use in p2p links.
Yep. Personally, I like the /64 per subnet including p2p link approach. Others have different opinions. Owen
----- Original Message ----- From: "Brandon Kim" <brandon.kim@brandontek.com> To: nanog@nanog.org Sent: Sunday, 17 October, 2010 8:58:57 AM Subject: RE: Definitive Guide to IPv6 adoption
Thanks everyone who responded. This list is such a valuable wealth of information.
Apparently I was wrong about the /64 as that should be /32 so thanks for that correction....
Thanks again especially on a Saturday weekend!
From: rdobbins@arbor.net To: nanog@nanog.org Date: Sat, 16 Oct 2010 16:09:43 +0000 Subject: Re: Definitive Guide to IPv6 adoption
On Oct 16, 2010, at 10:56 PM, Joel Jaeggli wrote:
Then move on to the Internet which as with most things is where the most cuurent if not helpful information resides.
Eric Vyncke's IPv6 security book is definitely worthwhile, as well, in combination with Schudel & Smith's infrastructure security book (the latter isn't IPv6-specific, but is the best book out there on infrastructure security):
<http://www.ciscopress.com/bookstore/product.asp?isbn=1587055945>
<http://www.ciscopress.com/bookstore/product.asp?isbn=1587053365>
----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Sell your computer and buy a guitar.
This 'get a /32' BAD ADVICE has got to stop. There are way too many people trying to force fit their customers into a block that is intended for a start-up with ZERO customers. Develop a plan for /48 per customer, then go to ARIN and get that size block. Figure out exactly what you are going to assign to customers later, but don't tie your hands by asking for a block that is way too small to begin with. Any ISP with more than 30k customers SHOULD NOT have a /32, and if they got one either trade it in or put it in a lab and get a REAL block. Tony
-----Original Message----- From: Brandon Kim [mailto:brandon.kim@brandontek.com] Sent: Saturday, October 16, 2010 1:59 PM To: nanog@nanog.org Subject: RE: Definitive Guide to IPv6 adoption
Thanks everyone who responded. This list is such a valuable wealth of information.
Apparently I was wrong about the /64 as that should be /32 so thanks for that correction....
Thanks again especially on a Saturday weekend!
From: rdobbins@arbor.net To: nanog@nanog.org Date: Sat, 16 Oct 2010 16:09:43 +0000 Subject: Re: Definitive Guide to IPv6 adoption
On Oct 16, 2010, at 10:56 PM, Joel Jaeggli wrote:
Then move on to the Internet which as with most things is where the most cuurent if not helpful information resides.
Eric Vyncke's IPv6 security book is definitely worthwhile, as well, in combination with Schudel & Smith's infrastructure security book (the latter isn't IPv6-specific, but is the best book out there on infrastructure security):
<http://www.ciscopress.com/bookstore/product.asp?isbn=1587055945>
<http://www.ciscopress.com/bookstore/product.asp?isbn=1587053365>
--------------------------------------------------------------------- -- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Sell your computer and buy a guitar.
=
On Oct 18, 2010, at 9:33 AM, Tony Hain wrote:
This 'get a /32' BAD ADVICE has got to stop. There are way too many people trying to force fit their customers into a block that is intended for a start-up with ZERO customers.
+1
Develop a plan for /48 per customer, then go to ARIN and get that size block. Figure out exactly what you are going to assign to customers later,
More accurately... A /48 per customer end-site...
but don't tie your hands by asking for a block that is way too small to begin with. Any ISP with more than 30k customers SHOULD NOT have a /32, and if they got one either trade it in or put it in a lab and get a REAL block.
But otherwise, yes, Tony is right. Owen
On 10/18/2010 11:45 AM, Owen DeLong wrote:
More accurately... A /48 per customer end-site...
Define end0-site. Residential customers, for example, don't need more than a /56. More would just be obscene. Most small businesses don't need more than a /56 either, especially if you are breaking them up into different sites (versus assigning a /48 to customer and dividing that block up to different sites). Jack
On 10/18/10 10:10 AM, Jack Bates wrote:
On 10/18/2010 11:45 AM, Owen DeLong wrote:
More accurately... A /48 per customer end-site...
Define end0-site. Residential customers, for example, don't need more than a /56.
This is a matter of opinion not gospel. larger, this size, or smaller needs to be justified by your deployment plan.
More would just be obscene. Most small businesses don't need more than a /56 either, especially if you are breaking them up into different sites (versus assigning a /48 to customer and dividing that block up to different sites).
business customers can and will do whatever is necessary to support their model. I have sought and received a /43 direct assignment for a business will multiple sites. I have no trouble imagining that my upstreams would accommodate requests for PA /48s for each location as well. joel
Jack
On Oct 18, 2010, at 10:10 AM, Jack Bates wrote:
On 10/18/2010 11:45 AM, Owen DeLong wrote:
More accurately... A /48 per customer end-site...
Define end0-site. Residential customers, for example, don't need more than a /56. More would just be obscene. Most small businesses don't need more than a /56 either, especially if you are breaking them up into different sites (versus assigning a /48 to customer and dividing that block up to different sites).
You are wrong. Residential customers should get /48s. /56s seemed like a good idea at the time, but, they aren't. It's not just about counting subnets. There's also the issue of needing bits for self-defining hierarchical topologies. 8 bits isn't enough for that. 16 is. Seriously... This isn't IPv4. The scarcity mentality is causing harm and driving decisions that will have a limiting effect on innovation that is already in progress. Owen
Unfortunately, it is not as easy as that in practice. I recently worked with a customer that has ~60,000 customers currently. We tried to get a larger block, but were denied. ARIN said they would only issue a /32, unless immediate usage could be shown that required more than that. Their guidelines also state /56 for end-users. I am a big proponent of nibble boundaries, too. I think if you are too big to use only a /32, you should get a /28, /24, and so forth. It would make routing so much nicer to deal with. /31 and such is just nasty. -Randy -- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 ---- ----- Original Message -----
This 'get a /32' BAD ADVICE has got to stop. There are way too many people trying to force fit their customers into a block that is intended for a start-up with ZERO customers.
Develop a plan for /48 per customer, then go to ARIN and get that size block. Figure out exactly what you are going to assign to customers later, but don't tie your hands by asking for a block that is way too small to begin with. Any ISP with more than 30k customers SHOULD NOT have a /32, and if they got one either trade it in or put it in a lab and get a REAL block.
Tony
-----Original Message----- From: Brandon Kim [mailto:brandon.kim@brandontek.com] Sent: Saturday, October 16, 2010 1:59 PM To: nanog@nanog.org Subject: RE: Definitive Guide to IPv6 adoption
Thanks everyone who responded. This list is such a valuable wealth of information.
Apparently I was wrong about the /64 as that should be /32 so thanks for that correction....
Thanks again especially on a Saturday weekend!
From: rdobbins@arbor.net To: nanog@nanog.org Date: Sat, 16 Oct 2010 16:09:43 +0000 Subject: Re: Definitive Guide to IPv6 adoption
On Oct 16, 2010, at 10:56 PM, Joel Jaeggli wrote:
Then move on to the Internet which as with most things is where the most cuurent if not helpful information resides.
Eric Vyncke's IPv6 security book is definitely worthwhile, as well, in combination with Schudel & Smith's infrastructure security book (the latter isn't IPv6-specific, but is the best book out there on infrastructure security):
<http://www.ciscopress.com/bookstore/product.asp?isbn=1587055945>
<http://www.ciscopress.com/bookstore/product.asp?isbn=1587053365>
--------------------------------------------------------------------- -- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Sell your computer and buy a guitar.
=
On 10/18/2010 11:47 AM, Randy Carpenter wrote:
Unfortunately, it is not as easy as that in practice.
I recently worked with a customer that has ~60,000 customers currently. We tried to get a larger block, but were denied. ARIN said they would only issue a /32, unless immediate usage could be shown that required more than that. Their guidelines also state /56 for end-users. I am a big proponent of nibble boundaries, too. I think if you are too big to use only a /32, you should get a /28, /24, and so forth. It would make routing so much nicer to deal with. /31 and such is just nasty.
ARIN does reservations (unsure at what length, but at least down to /31). If you were to fill the /32 quickly, you could easily request the next block. To my knowledge, they've only handed out 1 or 2 networks shorter than /32. Correct me if I'm wrong, but isn't 60,000 customers at /56 2^24 assignments from a /32? Seems plenty. Even at /48 assignments, you'd get 65,536 assignments. So how can you justify more than a /32? Jack
On Oct 18, 2010, at 9:59 AM, Jack Bates wrote:
On 10/18/2010 11:47 AM, Randy Carpenter wrote:
Unfortunately, it is not as easy as that in practice.
I recently worked with a customer that has ~60,000 customers currently. We tried to get a larger block, but were denied. ARIN said they would only issue a /32, unless immediate usage could be shown that required more than that. Their guidelines also state /56 for end-users. I am a big proponent of nibble boundaries, too. I think if you are too big to use only a /32, you should get a /28, /24, and so forth. It would make routing so much nicer to deal with. /31 and such is just nasty.
ARIN does reservations (unsure at what length, but at least down to /31). If you were to fill the /32 quickly, you could easily request the next block. To my knowledge, they've only handed out 1 or 2 networks shorter than /32.
Not any more... ARIN now uses allocation by bisection.
Correct me if I'm wrong, but isn't 60,000 customers at /56 2^24 assignments from a /32? Seems plenty. Even at /48 assignments, you'd get 65,536 assignments. So how can you justify more than a /32?
The customers should get /48s. The /56 guideline is merely that and only for the smallest of sites. It's also subsequently turned out to be bad advice. 60,000 customers may well be more than 65,536 end sites. Also, you need to leave room for numbering infrastructure, sizing POPs to prefixes, etc. It's much more complex than just number of customers = number of /48s. Unfortunately, current policy doesn't recognize that other than HD ratio. However, 60,000 customers each with a /48 would far exceed the .94 HD ratio requirement for larger than a /32. IIRC, under current policy it would justify a /30 or possibly a /29. Owen
On Mon, 18 Oct 2010, Owen DeLong wrote:
The customers should get /48s. The /56 guideline is merely that and only for the smallest of sites. It's also subsequently turned out to be bad advice.
Can you elaborate on why /56 is "bad advice" and if you're saying it only for this case or if you're saying assignment of /56 to any customers is a bad idea? Dealing with a data center where customer machines typically get by today with a /29 of IPv4, is a /56 really not enough for their forseeable future? I realize our /32 could support more customers than we're likely to fit in the data center at /48 per customer, but is that enough of a reason to assign 65k /64 subnets to each customer machine? ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Oct 18, 2010, at 11:18 AM, Jon Lewis wrote:
On Mon, 18 Oct 2010, Owen DeLong wrote:
The customers should get /48s. The /56 guideline is merely that and only for the smallest of sites. It's also subsequently turned out to be bad advice.
Can you elaborate on why /56 is "bad advice" and if you're saying it only for this case or if you're saying assignment of /56 to any customers is a bad idea? Dealing with a data center where customer machines typically get by today with a /29 of IPv4, is a /56 really not enough for their forseeable future?
I think it's generally a bad idea. /48 is the design architecture for IPv6. It allows for significant innovation in the SOHO arena that we haven't accounted for in some of our current thinking. In a datacenter environment, you might want to actually assign /64s to needed subnets, but, in a situation where you are serving remote end-sites, a /48 per end-site is, IMHO, the minimum size that should be issued.
I realize our /32 could support more customers than we're likely to fit in the data center at /48 per customer, but is that enough of a reason to assign 65k /64 subnets to each customer machine?
Datacenter is a whole different ball of wax. Nothing wrong with giving your customers /48s, but, the right size in a datacenter may well depend on a lot of things about your business model, the nature of your customers, etc. Certainly I would not deny a /48 to any customer that requested one. Owen
On Mon, 18 Oct 2010, Owen DeLong wrote:
I think it's generally a bad idea. /48 is the design architecture for IPv6. It allows for significant innovation in the SOHO arena that we haven't accounted for in some of our current thinking.
Q: Why are /48s everywhere a good idea? A: Because it's the design! Q: Why are /48s everywhere in the design? A? Because it's a good idea! This kind of crap is one of the reasons people get frustrated with IPv6 zealotry. If people are actually interested in deploying IPv6 then by all means, STOP BITCHING AT THEM ABOUT HOW THEY DO IT. Problems like the wrong allocation to end users are fixable, especially given that the vast majority of end user assignments are dynamic in the first place. The model I've been advocating is for ISPs (who have enough space) to start off reserving a /48 per customer and then assigning the first /56 from it. If after real operational experience it turns out /48 is the right answer, you're all set. If /56 turns out to be sufficient, when you use up all of the first /56s you can start on the first /56 in the second /49, etc. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso
On 10/18/2010 14:39, Doug Barton wrote:
On Mon, 18 Oct 2010, Owen DeLong wrote:
I think it's generally a bad idea. /48 is the design architecture for IPv6. It allows for significant innovation in the SOHO arena that we haven't accounted for in some of our current thinking.
Q: Why are /48s everywhere a good idea? A: Because it's the design!
Q: Why are /48s everywhere in the design? A? Because it's a good idea!
This kind of crap is one of the reasons people get frustrated with IPv6 zealotry. If people are actually interested in deploying IPv6 then by all means, STOP BITCHING AT THEM ABOUT HOW THEY DO IT. Problems like the wrong allocation to end users are fixable, especially given that the vast majority of end user assignments are dynamic in the first place.
Dynamic under IPv4, that is. It could be argued that IPv6 brings back the ability to go static everywhere again. ~Seth
On Mon, 18 Oct 2010 14:39:19 -0700 (PDT) Doug Barton <dougb@dougbarton.us> wrote:
On Mon, 18 Oct 2010, Owen DeLong wrote:
I think it's generally a bad idea. /48 is the design architecture for IPv6. It allows for significant innovation in the SOHO arena that we haven't accounted for in some of our current thinking.
Q: Why are /48s everywhere a good idea? A: Because it's the design!
Q: Why are /48s everywhere in the design? A? Because it's a good idea!
This kind of crap is one of the reasons people get frustrated with IPv6 zealotry. If people are actually interested in deploying IPv6 then by all means, STOP BITCHING AT THEM ABOUT HOW THEY DO IT. Problems like the wrong allocation to end users are fixable, especially given that the vast majority of end user assignments are dynamic in the first place.
The model I've been advocating is for ISPs (who have enough space) to start off reserving a /48 per customer and then assigning the first /56 from it. If after real operational experience it turns out /48 is the right answer, you're all set. If /56 turns out to be sufficient, when you use up all of the first /56s you can start on the first /56 in the second /49, etc.
While I like the idea of /48s per customer ("per-nearly everybody"), I do think this approach is a good, slightly more conservative approach. Regards, Mark.
On Oct 18, 2010, at 2:39 PM, Doug Barton wrote:
On Mon, 18 Oct 2010, Owen DeLong wrote:
I think it's generally a bad idea. /48 is the design architecture for IPv6. It allows for significant innovation in the SOHO arena that we haven't accounted for in some of our current thinking.
Q: Why are /48s everywhere a good idea? A: Because it's the design!
Q: Why are /48s everywhere in the design? A? Because it's a good idea!
Which of course ignores the second half of my comment...
This kind of crap is one of the reasons people get frustrated with IPv6 zealotry. If people are actually interested in deploying IPv6 then by all means, STOP BITCHING AT THEM ABOUT HOW THEY DO IT. Problems like the wrong allocation to end users are fixable, especially given that the vast majority of end user assignments are dynamic in the first place.
Unless those problems become endemic and start reducing the lowest common denominator to which vendors feel they must implement. There are advantages to being able to use 16 bits to build various forms of hierarchical topology on a dynamic basis within a SOHO environment. If we reduce that to 8 bits, we will block innovations that are currently underway in this space.
The model I've been advocating is for ISPs (who have enough space) to start off reserving a /48 per customer and then assigning the first /56 from it. If after real operational experience it turns out /48 is the right answer, you're all set. If /56 turns out to be sufficient, when you use up all of the first /56s you can start on the first /56 in the second /49, etc.
Uh, yeah, why not just get your /32 (or whatever larger prefix you started with) expanded or get an additional prefix to put the additional customers into? Then, you're still set and you haven't had to block or reduce capabilities your customers should be able to accept. Owen
On Tue, 19 Oct 2010, Owen DeLong wrote:
There are advantages to being able to use 16 bits to build various forms of hierarchical topology on a dynamic basis within a SOHO environment. If we reduce that to 8 bits, we will block innovations that are currently underway in this space.
Can you give us some examples of these innovations that are currently underway? Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD.
On Oct 19, 2010, at 5:21 AM, Tony Finch wrote:
On Tue, 19 Oct 2010, Owen DeLong wrote:
There are advantages to being able to use 16 bits to build various forms of hierarchical topology on a dynamic basis within a SOHO environment. If we reduce that to 8 bits, we will block innovations that are currently underway in this space.
Can you give us some examples of these innovations that are currently underway?
I have, and, Tony Hain does a better job, but, here goes: Imagine any or all of the following possibilities: Sensor networks within appliances with the appliance acting as a router Each home entertainment center is a collection of networked components with a router fronting each center. Kids networks with different filtration and security policies from those used by the adults in the house. Guest wireless networks. Groceries coming with RFID tags that your refrigerator and cabinets can use to identify their contents. A web server embedded in your kitchen router that fronts these networks can be queried from your cell phone while you are at the store to find out what you are running low on in real time. I'm sure there are more, but, these are things that could be done relatively easily with existing technology. Owen
On Oct 18, 2010, at 6:59 AM, Jack Bates wrote:
ARIN does reservations (unsure at what length, but at least down to /31).
Do they still do that? Back when I was at IANA, one of the justifications the RIRs gave for the /12s they received was that they were going to be using the 'bisection' method of allocation which removes the need for reservation. Last I heard, APNIC was using the bisection method... Regards, -drc
On Oct 18, 2010, at 2:18 PM, David Conrad wrote:
On Oct 18, 2010, at 6:59 AM, Jack Bates wrote:
ARIN does reservations (unsure at what length, but at least down to /31).
Do they still do that? Back when I was at IANA, one of the justifications the RIRs gave for the /12s they received was that they were going to be using the 'bisection' method of allocation which removes the need for reservation. Last I heard, APNIC was using the bisection method...
ARIN is doing the same (the 'bisection' method) with our IPv6 management since January 2010: we refer to the "sparse allocation" approach and it was requested by the community during the ARIN/NANOG Dearborn meeting. FYI, /John John Curran President and CEO ARIN
John, Can you tell us at what degree the bisection stops? i.e. does it keep going until there are no spaces left, or will you leave some space in between each one to leave some room for future needs for orgs that already have allocations? -Randy -- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 ---- ----- Original Message -----
On Oct 18, 2010, at 2:18 PM, David Conrad wrote:
On Oct 18, 2010, at 6:59 AM, Jack Bates wrote:
ARIN does reservations (unsure at what length, but at least down to /31).
Do they still do that? Back when I was at IANA, one of the justifications the RIRs gave for the /12s they received was that they were going to be using the 'bisection' method of allocation which removes the need for reservation. Last I heard, APNIC was using the bisection method...
ARIN is doing the same (the 'bisection' method) with our IPv6 management since January 2010: we refer to the "sparse allocation" approach and it was requested by the community during the ARIN/NANOG Dearborn meeting.
FYI, /John
John Curran President and CEO ARIN
Randy - We'll likely put that out to the ARIN community for consultation at the point in time when becomes a potential issue. I expect we will have plenty of time before that needs to be considered at the present rate of allocation. /John John Curran President and CEO ARIN On Oct 18, 2010, at 3:08 PM, Randy Carpenter wrote:
John,
Can you tell us at what degree the bisection stops? i.e. does it keep going until there are no spaces left, or will you leave some space in between each one to leave some room for future needs for orgs that already have allocations?
-Randy
-- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 ----
----- Original Message -----
On Oct 18, 2010, at 2:18 PM, David Conrad wrote:
On Oct 18, 2010, at 6:59 AM, Jack Bates wrote:
ARIN does reservations (unsure at what length, but at least down to /31).
Do they still do that? Back when I was at IANA, one of the justifications the RIRs gave for the /12s they received was that they were going to be using the 'bisection' method of allocation which removes the need for reservation. Last I heard, APNIC was using the bisection method...
ARIN is doing the same (the 'bisection' method) with our IPv6 management since January 2010: we refer to the "sparse allocation" approach and it was requested by the community during the ARIN/NANOG Dearborn meeting.
FYI, /John
John Curran President and CEO ARIN
I have a few customers whose allocations are /29 away from their nearest neighbor (half a nibble). That seems a little close considering there is a lot of talk about doing nibble boundaries, and there doesn't seem to be consensus yet. For these customers, I don't think they will need more than a /29, but if we collectively decide that a /28 is the next step from a /32, how will the older allocations be dealt with? This is pretty much a rhetorical question at this point, and I suppose the proper thing to do is to channel these questions toward the PPML for discussion as potential policy. thanks, -Randy -- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 ---- ----- Original Message -----
Randy -
We'll likely put that out to the ARIN community for consultation at the point in time when becomes a potential issue. I expect we will have plenty of time before that needs to be considered at the present rate of allocation.
/John
John Curran President and CEO ARIN
On Oct 18, 2010, at 3:08 PM, Randy Carpenter wrote:
John,
Can you tell us at what degree the bisection stops? i.e. does it keep going until there are no spaces left, or will you leave some space in between each one to leave some room for future needs for orgs that already have allocations?
-Randy
-- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 ----
----- Original Message -----
On Oct 18, 2010, at 2:18 PM, David Conrad wrote:
On Oct 18, 2010, at 6:59 AM, Jack Bates wrote:
ARIN does reservations (unsure at what length, but at least down to /31).
Do they still do that? Back when I was at IANA, one of the justifications the RIRs gave for the /12s they received was that they were going to be using the 'bisection' method of allocation which removes the need for reservation. Last I heard, APNIC was using the bisection method...
ARIN is doing the same (the 'bisection' method) with our IPv6 management since January 2010: we refer to the "sparse allocation" approach and it was requested by the community during the ARIN/NANOG Dearborn meeting.
FYI, /John
John Curran President and CEO ARIN
On 10/18/10 12:42 PM, Randy Carpenter wrote:
I have a few customers whose allocations are /29 away from their nearest neighbor (half a nibble). That seems a little close considering there is a lot of talk about doing nibble boundaries, and there doesn't seem to be consensus yet.
For these customers, I don't think they will need more than a /29, but if we collectively decide that a /28 is the next step from a /32, how will the older allocations be dealt with? This is pretty much a rhetorical question at this point, and I suppose the proper thing to do is to channel these questions toward the PPML for discussion as potential policy.
back in the distant past we were issued a /35, policy changed, we returned it and on 2001 7/11 we were issued our current /32
thanks, -Randy
-- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 ----
----- Original Message -----
Randy -
We'll likely put that out to the ARIN community for consultation at the point in time when becomes a potential issue. I expect we will have plenty of time before that needs to be considered at the present rate of allocation.
/John
John Curran President and CEO ARIN
On Oct 18, 2010, at 3:08 PM, Randy Carpenter wrote:
John,
Can you tell us at what degree the bisection stops? i.e. does it keep going until there are no spaces left, or will you leave some space in between each one to leave some room for future needs for orgs that already have allocations?
-Randy
-- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 ----
----- Original Message -----
On Oct 18, 2010, at 2:18 PM, David Conrad wrote:
On Oct 18, 2010, at 6:59 AM, Jack Bates wrote:
ARIN does reservations (unsure at what length, but at least down to /31).
Do they still do that? Back when I was at IANA, one of the justifications the RIRs gave for the /12s they received was that they were going to be using the 'bisection' method of allocation which removes the need for reservation. Last I heard, APNIC was using the bisection method...
ARIN is doing the same (the 'bisection' method) with our IPv6 management since January 2010: we refer to the "sparse allocation" approach and it was requested by the community during the ARIN/NANOG Dearborn meeting.
FYI, /John
John Curran President and CEO ARIN
Generally the older allocations would be left in place until deprecated by attrition. At least that's what I plan to advocate in my policy proposal. Owen Sent from my iPad On Oct 18, 2010, at 12:42 PM, Randy Carpenter <rcarpen@network1.net> wrote:
I have a few customers whose allocations are /29 away from their nearest neighbor (half a nibble). That seems a little close considering there is a lot of talk about doing nibble boundaries, and there doesn't seem to be consensus yet.
For these customers, I don't think they will need more than a /29, but if we collectively decide that a /28 is the next step from a /32, how will the older allocations be dealt with? This is pretty much a rhetorical question at this point, and I suppose the proper thing to do is to channel these questions toward the PPML for discussion as potential policy.
thanks, -Randy
-- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 ----
----- Original Message -----
Randy -
We'll likely put that out to the ARIN community for consultation at the point in time when becomes a potential issue. I expect we will have plenty of time before that needs to be considered at the present rate of allocation.
/John
John Curran President and CEO ARIN
On Oct 18, 2010, at 3:08 PM, Randy Carpenter wrote:
John,
Can you tell us at what degree the bisection stops? i.e. does it keep going until there are no spaces left, or will you leave some space in between each one to leave some room for future needs for orgs that already have allocations?
-Randy
-- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 ----
----- Original Message -----
On Oct 18, 2010, at 2:18 PM, David Conrad wrote:
On Oct 18, 2010, at 6:59 AM, Jack Bates wrote:
ARIN does reservations (unsure at what length, but at least down to /31).
Do they still do that? Back when I was at IANA, one of the justifications the RIRs gave for the /12s they received was that they were going to be using the 'bisection' method of allocation which removes the need for reservation. Last I heard, APNIC was using the bisection method...
ARIN is doing the same (the 'bisection' method) with our IPv6 management since January 2010: we refer to the "sparse allocation" approach and it was requested by the community during the ARIN/NANOG Dearborn meeting.
FYI, /John
John Curran President and CEO ARIN
On Oct 18, 2010, at 3:42 PM, Randy Carpenter wrote:
I have a few customers whose allocations are /29 away from their nearest neighbor (half a nibble). That seems a little close considering there is a lot of talk about doing nibble boundaries, and there doesn't seem to be consensus yet.
For these customers, I don't think they will need more than a /29, but if we collectively decide that a /28 is the next step from a /32, how will the older allocations be dealt with? This is pretty much a rhetorical question at this point, and I suppose the proper thing to do is to channel these questions toward the PPML for discussion as potential policy.
Just for reference regarding existing IPv6 sparse practice: Our current plan is to use the sparse allocation block (currently a /14) until we fill it up. Bisection done at the /28 boundary which leaves a fairly large reserve. If an organization needs an allocation larger than a /28, we have set aside a /15 block for those larger ISPs. The orgs that already have allocations (/32s from /29s) also have a reserve. If they need additional space, they can either request from their /29 reserve, or if they need more than a /29, can request a new block. Obviously, this can be changed if the community wishes it so. Bring any obvious suggestions to the ARIN suggestion process, and anything which might be contentious or affect allocations to the policy process. Thanks! /John John Curran President and CEO ARIN
John, Thank you very much. That clarification helps out quite a bit. -Randy -- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 ---- ----- Original Message -----
On Oct 18, 2010, at 3:42 PM, Randy Carpenter wrote:
I have a few customers whose allocations are /29 away from their nearest neighbor (half a nibble). That seems a little close considering there is a lot of talk about doing nibble boundaries, and there doesn't seem to be consensus yet.
For these customers, I don't think they will need more than a /29, but if we collectively decide that a /28 is the next step from a /32, how will the older allocations be dealt with? This is pretty much a rhetorical question at this point, and I suppose the proper thing to do is to channel these questions toward the PPML for discussion as potential policy.
Just for reference regarding existing IPv6 sparse practice:
Our current plan is to use the sparse allocation block (currently a /14) until we fill it up. Bisection done at the /28 boundary which leaves a fairly large reserve.
If an organization needs an allocation larger than a /28, we have set aside a /15 block for those larger ISPs.
The orgs that already have allocations (/32s from /29s) also have a reserve. If they need additional space, they can either request from their /29 reserve, or if they need more than a /29, can request a new block.
Obviously, this can be changed if the community wishes it so. Bring any obvious suggestions to the ARIN suggestion process, and anything which might be contentious or affect allocations to the policy process.
Thanks! /John
John Curran President and CEO ARIN
On Oct 18, 2010, at 11:18 AM, David Conrad wrote:
On Oct 18, 2010, at 6:59 AM, Jack Bates wrote:
ARIN does reservations (unsure at what length, but at least down to /31).
Do they still do that? Back when I was at IANA, one of the justifications the RIRs gave for the /12s they received was that they were going to be using the 'bisection' method of allocation which removes the need for reservation. Last I heard, APNIC was using the bisection method...
Regards, -drc
No, ARIN converted to bisection quite some time ago. Owen
On Oct 18, 2010, at 9:47 AM, Randy Carpenter wrote:
Unfortunately, it is not as easy as that in practice.
I recently worked with a customer that has ~60,000 customers currently. We tried to get a larger block, but were denied. ARIN said they would only issue a /32, unless immediate usage could be shown that required more than that. Their guidelines also state /56 for end-users. I am a big proponent of nibble boundaries, too. I think if you are too big to use only a /32, you should get a /28, /24, and so forth. It would make routing so much nicer to deal with. /31 and such is just nasty.
ARIN policy allows for a /48 per end user. There are guidelines included in the policy that allow for a /56 per end-user, but, they are explicitly called out as just guidelines, not policy. I am working on changing the ARIN policy (I've currently circulated a draft to some co-authors and expect to be posting it to policy@arin.net and ppml@arin.net within the next couple of weeks) along the lines you mention. I think that IPv4think is a largely temporary problem, but, it is a problem even at the RIRs. Owen
-Randy
-- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 ----
----- Original Message -----
This 'get a /32' BAD ADVICE has got to stop. There are way too many people trying to force fit their customers into a block that is intended for a start-up with ZERO customers.
Develop a plan for /48 per customer, then go to ARIN and get that size block. Figure out exactly what you are going to assign to customers later, but don't tie your hands by asking for a block that is way too small to begin with. Any ISP with more than 30k customers SHOULD NOT have a /32, and if they got one either trade it in or put it in a lab and get a REAL block.
Tony
-----Original Message----- From: Brandon Kim [mailto:brandon.kim@brandontek.com] Sent: Saturday, October 16, 2010 1:59 PM To: nanog@nanog.org Subject: RE: Definitive Guide to IPv6 adoption
Thanks everyone who responded. This list is such a valuable wealth of information.
Apparently I was wrong about the /64 as that should be /32 so thanks for that correction....
Thanks again especially on a Saturday weekend!
From: rdobbins@arbor.net To: nanog@nanog.org Date: Sat, 16 Oct 2010 16:09:43 +0000 Subject: Re: Definitive Guide to IPv6 adoption
On Oct 16, 2010, at 10:56 PM, Joel Jaeggli wrote:
Then move on to the Internet which as with most things is where the most cuurent if not helpful information resides.
Eric Vyncke's IPv6 security book is definitely worthwhile, as well, in combination with Schudel & Smith's infrastructure security book (the latter isn't IPv6-specific, but is the best book out there on infrastructure security):
<http://www.ciscopress.com/bookstore/product.asp?isbn=1587055945>
<http://www.ciscopress.com/bookstore/product.asp?isbn=1587053365>
--------------------------------------------------------------------- -- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Sell your computer and buy a guitar.
=
On 10/18/10 9:33 AM, Tony Hain wrote:
This 'get a /32' BAD ADVICE has got to stop. There are way too many people trying to force fit their customers into a block that is intended for a start-up with ZERO customers.
Develop a plan for /48 per customer, then go to ARIN and get that size block.
Develop a plan, consider the prior art, consider the possibly that you might deploy 6rd, consider what your peers are doing, consider the projections for your business. Go to arin with a request that meets your current and anticipated needs and that is defensible. don't decide without thinking it through that you're assigning a customer a /64 a /60 a /56 or even /48. this should be defensible as part of a business plan, otherwise what's the point?
Figure out exactly what you are going to assign to customers later, but don't tie your hands by asking for a block that is way too small to begin with. Any ISP with more than 30k customers SHOULD NOT have a /32, and if they got one either trade it in or put it in a lab and get a REAL block.
Tony
-----Original Message----- From: Brandon Kim [mailto:brandon.kim@brandontek.com] Sent: Saturday, October 16, 2010 1:59 PM To: nanog@nanog.org Subject: RE: Definitive Guide to IPv6 adoption
Thanks everyone who responded. This list is such a valuable wealth of information.
Apparently I was wrong about the /64 as that should be /32 so thanks for that correction....
Thanks again especially on a Saturday weekend!
From: rdobbins@arbor.net To: nanog@nanog.org Date: Sat, 16 Oct 2010 16:09:43 +0000 Subject: Re: Definitive Guide to IPv6 adoption
On Oct 16, 2010, at 10:56 PM, Joel Jaeggli wrote:
Then move on to the Internet which as with most things is where the most cuurent if not helpful information resides.
Eric Vyncke's IPv6 security book is definitely worthwhile, as well, in combination with Schudel & Smith's infrastructure security book (the latter isn't IPv6-specific, but is the best book out there on infrastructure security):
<http://www.ciscopress.com/bookstore/product.asp?isbn=1587055945>
<http://www.ciscopress.com/bookstore/product.asp?isbn=1587053365>
--------------------------------------------------------------------- -- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Sell your computer and buy a guitar.
=
On Oct 18, 2010, at 9:53 AM, Joel Jaeggli wrote:
On 10/18/10 9:33 AM, Tony Hain wrote:
This 'get a /32' BAD ADVICE has got to stop. There are way too many people trying to force fit their customers into a block that is intended for a start-up with ZERO customers.
Develop a plan for /48 per customer, then go to ARIN and get that size block.
Develop a plan, consider the prior art, consider the possibly that you might deploy 6rd, consider what your peers are doing, consider the projections for your business. Go to arin with a request that meets your current and anticipated needs and that is defensible.
don't decide without thinking it through that you're assigning a customer a /64 a /60 a /56 or even /48. this should be defensible as part of a business plan, otherwise what's the point?
A /48 is defensible. It's the architecturally intended end-site configuration, it is allowed by policy, and, it is a reasonable starting point. There is no real reason to assign less than a /48 to any end-site other than hyper- conservatism due to IPv4-think. Owen
Figure out exactly what you are going to assign to customers later, but don't tie your hands by asking for a block that is way too small to begin with. Any ISP with more than 30k customers SHOULD NOT have a /32, and if they got one either trade it in or put it in a lab and get a REAL block.
Tony
-----Original Message----- From: Brandon Kim [mailto:brandon.kim@brandontek.com] Sent: Saturday, October 16, 2010 1:59 PM To: nanog@nanog.org Subject: RE: Definitive Guide to IPv6 adoption
Thanks everyone who responded. This list is such a valuable wealth of information.
Apparently I was wrong about the /64 as that should be /32 so thanks for that correction....
Thanks again especially on a Saturday weekend!
From: rdobbins@arbor.net To: nanog@nanog.org Date: Sat, 16 Oct 2010 16:09:43 +0000 Subject: Re: Definitive Guide to IPv6 adoption
On Oct 16, 2010, at 10:56 PM, Joel Jaeggli wrote:
Then move on to the Internet which as with most things is where the most cuurent if not helpful information resides.
Eric Vyncke's IPv6 security book is definitely worthwhile, as well, in combination with Schudel & Smith's infrastructure security book (the latter isn't IPv6-specific, but is the best book out there on infrastructure security):
<http://www.ciscopress.com/bookstore/product.asp?isbn=1587055945>
<http://www.ciscopress.com/bookstore/product.asp?isbn=1587053365>
--------------------------------------------------------------------- -- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Sell your computer and buy a guitar.
=
don't decide without thinking it through that you're assigning a customer a /64 a /60 a /56 or even /48. this should be defensible as part of a business plan, otherwise what's the point?
A /48 is defensible. It's the architecturally intended end-site configuration, it is allowed by policy, and, it is a reasonable starting point. There is no real reason to assign less than a /48 to any end-site other than hyper- conservatism due to IPv4-think.
I still haven't seen any good argument for why residential users need /48s. No, I don't think "that makes all the address assignments the same size" is a particularly relevant or convincing argument. We're doing /56 for residential users, and have no plans to change this. Steinar Haug, Nethelp consulting, sthaug@nethelp.no
On 10/18/2010 1:20 PM, sthaug@nethelp.no wrote:
I still haven't seen any good argument for why residential users need /48s. No, I don't think "that makes all the address assignments the same size" is a particularly relevant or convincing argument.
We're doing /56 for residential users, and have no plans to change this.
+1 This not only makes pop assignments easier, it gives a much larger prefix rotation pool. Don't start the flame on rotating prefixes being evil. It's my implementation to at least give customers some chance at prefix privacy. Jack
So they can't run their own services from home and have to request premium connectivity from you? Beside the IPv4 scarcity mentality we have the Telco mentality to fight... Happy days still ahead... ----- Original Message ----- From: "Jack Bates" <jbates@brightok.net> To: sthaug@nethelp.no Cc: nanog@nanog.org Sent: Tuesday, 19 October, 2010 8:10:35 AM Subject: Re: Definitive Guide to IPv6 adoption On 10/18/2010 1:20 PM, sthaug@nethelp.no wrote:
I still haven't seen any good argument for why residential users need /48s. No, I don't think "that makes all the address assignments the same size" is a particularly relevant or convincing argument.
We're doing /56 for residential users, and have no plans to change this.
+1 This not only makes pop assignments easier, it gives a much larger prefix rotation pool. Don't start the flame on rotating prefixes being evil. It's my implementation to at least give customers some chance at prefix privacy. Jack
On 10/18/2010 3:51 PM, Franck Martin wrote:
So they can't run their own services from home and have to request premium connectivity from you?
Beside the IPv4 scarcity mentality we have the Telco mentality to fight...
Happy days still ahead...
Of course they can run their own services at home. How does renumber effect that (outside of poor v6 implementations at this late stage)? v6 is designed to support multiple prefixes and the ability to change from one prefix to another with limited disruption, especially if I give 24 hours to complete the transition. If servers and services can't handle this, I'd say they need to improve, or the customer will need a static allocation, which we may or may not charge for (depending on how automated we make it). A sane default of rotation is appropriate for us, though, and no amount of fighting by anyone will make the Telco think that google or others have the right to track their users. It's unfair for our users who block cookies, do due diligence to not be tracked, and then we throw them to the wolves with a constant trackable prefix. Jack (knew this would start an argument. *sigh*)
So they can't run their own services from home and have to request
-----Original Message----- From: Jack Bates [mailto:jbates@brightok.net] Sent: Monday, October 18, 2010 5:12 PM To: Franck Martin Cc: nanog@nanog.org Subject: Re: Definitive Guide to IPv6 adoption On 10/18/2010 3:51 PM, Franck Martin wrote: premium connectivity from you?
Beside the IPv4 scarcity mentality we have the Telco mentality to
fight...
Happy days still ahead...
Of course they can run their own services at home. How does renumber effect that (outside of poor v6 implementations at this late stage)? v6 is designed to support multiple prefixes and the ability to change from one prefix to another with limited disruption, especially if I give 24 hours to complete the transition. If servers and services can't handle this, I'd say they need to improve, or the customer will need a static allocation, which we may or may not charge for (depending on how automated we make it). A sane default of rotation is appropriate for us, though, and no amount of fighting by anyone will make the Telco think that google or others have the right to track their users. It's unfair for our users who block cookies, do due diligence to not be tracked, and then we throw them to the wolves with a constant trackable prefix. HS: Where customers = spammers? The only folks I have seen ask to do 'address rotation' have either been spammers or copyright monitoring services. I have never seen a request for 'address rotation' to protect a customer from Google. Wouldn't you just tell them not to use Google's services? The *typical* residential user doesn't know and probably doesn't care whether their prefix is dynamic or static. Dynamic allocation of address space was, in part, meant to help conserve space - if the prefix was only needed for a couple hours, it could in theory be released and reused... allowing more efficient utilization of space. Now though, with always-on connections and folks wanting to access their content remotely - it makes sense to statically allocate prefixes... and the availability of addresses in IPv6 gives us the room to do this. Jack (knew this would start an argument. *sigh*)
On 10/19/2010 11:53 AM, Schiller, Heather A (HeatherSkanks) wrote:
HS: Where customers = spammers? The only folks I have seen ask to do 'address rotation' have either been spammers or copyright monitoring services. I have never seen a request for 'address rotation' to protect a customer from Google. Wouldn't you just tell them not to use Google's services? The *typical* residential user doesn't know and probably doesn't care whether their prefix is dynamic or static.
The typical resident often doesn't know, but when asked, they do want privacy, and they don't want to be tracked by various databases for marketing or geoIP tracking. Some customers prefer static, but to date, the only reason customers have asked for static in v4 is because it was necessary. If v6 continues to support application and design for renumbering, such statics won't be necessary and I'll have even fewer requests.
Dynamic allocation of address space was, in part, meant to help conserve space - if the prefix was only needed for a couple hours, it could in theory be released and reused... allowing more efficient utilization of space. Now though, with always-on connections and folks wanting to access their content remotely - it makes sense to statically allocate prefixes... and the availability of addresses in IPv6 gives us the room to do this.
With the new capabilities of multiple prefixes and renumbering capabilities and the various methodologies which will be used to easily switch between providers (or balance traffic between multiple providers using multiple prefixes), rotating prefixes every 24 hours shouldn't be a big deal. The customer will still gain remote access to their content, while also remaining a moving target. Customer's care about privacy, even when they don't realize if they truly have it or not. M$ considered privacy extensions on by default to be a good thing. I'm just extending it to the prefix. You can change nic cards as easily as you change ISPs (easier out here, actually). As customers actually notice or care that they are using v6, I'm sure I'll have more static requests as well, which we'll probably automate. Jack
On Oct 18, 2010, at 1:10 PM, Jack Bates wrote:
On 10/18/2010 1:20 PM, sthaug@nethelp.no wrote:
I still haven't seen any good argument for why residential users need /48s. No, I don't think "that makes all the address assignments the same size" is a particularly relevant or convincing argument.
We're doing /56 for residential users, and have no plans to change this.
+1
This not only makes pop assignments easier, it gives a much larger prefix rotation pool. Don't start the flame on rotating prefixes being evil. It's my implementation to at least give customers some chance at prefix privacy.
What if your customers don't want prefix privacy and prefer, instead, to have the option of accessing their resources remotely, setting up mobile-IP home gateways, and any of the other functions that come from static prefixes? Finally, no, /56 isn't a great idea for other reasons. Sure, it will meet today's needs, but, it ignores a future in which households aren't simple flat topologies, but, instead have multiple layers of routers dynamically determining hierarchies and building topologies to meet a variety of needs not yet addressable due to the current limitations of IPv4. This isn't pie in the sky science fiction. Most of the technology exists today and all that is left is the deployment of sufficient address resources to the consumer and some integration work at the vendor level. Owen
On 10/19/10, Owen DeLong <owen@delong.com> wrote:
On Oct 18, 2010, at 1:10 PM, Jack Bates wrote:
On 10/18/2010 1:20 PM, sthaug@nethelp.no wrote:
I still haven't seen any good argument for why residential users need /48s. No, I don't think "that makes all the address assignments the same size" is a particularly relevant or convincing argument.
We're doing /56 for residential users, and have no plans to change this.
+1
This not only makes pop assignments easier, it gives a much larger prefix rotation pool. Don't start the flame on rotating prefixes being evil. It's my implementation to at least give customers some chance at prefix privacy.
What if your customers don't want prefix privacy and prefer, instead, to have the option of accessing their resources remotely, setting up mobile-IP home gateways, and any of the other functions that come from static prefixes?
Why does it have to be one or the other? Isn't it possible to hand out a static assignment so that users can access their resources remotely as well as handing out a rotating prefix that changes every so often so that users have 'some chance at prefix privacy.' Lee
sthaug@nethelp.no writes:
I still haven't seen any good argument for why residential users need /48s. No, I don't think "that makes all the address assignments the same size" is a particularly relevant or convincing argument.
We're doing /56 for residential users, and have no plans to change this.
If we were to give a /48 to every human on the face of the planet, we would use about .000025 of the total available IPv6 address space. You are to be commended for your leadership in conserving space. Our children will surely be grateful that thanks to your efforts they have 99.99999% of IPv6 space left to work with rather than the paltry 99.9975% that might have been their inheritance were it not for your efforts. Bravo! -r
On Oct 18, 2010, at 8:16 PM, Robert E. Seastrom wrote:
sthaug@nethelp.no writes:
I still haven't seen any good argument for why residential users need /48s. No, I don't think "that makes all the address assignments the same size" is a particularly relevant or convincing argument.
We're doing /56 for residential users, and have no plans to change this.
If we were to give a /48 to every human on the face of the planet, we would use about .000025 of the total available IPv6 address space.
You are to be commended for your leadership in conserving space. Our children will surely be grateful that thanks to your efforts they have 99.99999% of IPv6 space left to work with rather than the paltry 99.9975% that might have been their inheritance were it not for your efforts. Bravo!
It makes a bigger difference if everyone starts using 6RD - to give out a /48 effectively requires a /16, and the number of /16s is by no means approximately infinite. Regards Marshall
-r
Marshall Eubanks <tme@americafree.tv> writes:
It makes a bigger difference if everyone starts using 6RD - to give out a /48 effectively requires a /16, and the number of /16s is by no means approximately infinite.
Don't I know it! Poorly designed protocol, but what're we gonna do? I was of the "a /56 was bad enough, don't let the standard what-people-expect slip to a /60" school. I'm pleased that the ARIN AC passed 2010-12 with provision for getting a /24. Keeps the damage from getting worse. But for native deployment, absolutely just provision the /48. -r
In message <35804BC3-9EFE-4CE4-B13A-F2E15C420EFA@americafree.tv>, Marshall Euba nks writes:
It makes a bigger difference if everyone starts using 6RD - to give out = a /48 effectively=20 requires a /16, and the number of /16s is by no means approximately = infinite.=20
Regards Marshall
Only if you deploy 6rd in a naive manner. Encoding all of IPv4 into the IPv6 prefix you hand your customers in naive. The best way is to just have a table that matches 6rd prefixes to IPv4 blocks you have assigned. This table only changes when you add or remove a IPv4 assignments from RIRs. You don't change existing entries in the table. The entries are static for the life of the IPv4 allocation. <6rdPrefix1><6rdPefixLen1><IPv4Prefix1><IPv4PrefixLen1> <6rdPrefix2><6rdPefixLen2><IPv4Prefix2><IPv4PrefixLen2> <6rdPrefix3><6rdPefixLen3><IPv4Prefix3><IPv4PrefixLen3> When you configure a IPv4 DHCP pool and associated router interface you find the covering IPv4 prefix and plug in the values from the table. The next best way is to have a similar table but per covering IPv4/8 you have allocated. This is very wasteful but not as having a IPv4PrefixLen of 0. <6rdPrefix1><6rdPefixLen><192.0.0.0><8> <6rdPrefix2><6rdPefixLen><202.0.0.0><8> For the global naive case the table degenerates to a single row. <6rdPrefix><6rdPefixLen><0.0.0.0><0> As a exercise the first table was ~20 entries for Comcast Cable and the second table about ~10 entries if I did the lookup correctly so we are not talking about a lot of prefixes and they don't change very often. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Oct 18, 2010, at 5:45 PM, Marshall Eubanks wrote:
On Oct 18, 2010, at 8:16 PM, Robert E. Seastrom wrote:
sthaug@nethelp.no writes:
I still haven't seen any good argument for why residential users need /48s. No, I don't think "that makes all the address assignments the same size" is a particularly relevant or convincing argument.
We're doing /56 for residential users, and have no plans to change this.
If we were to give a /48 to every human on the face of the planet, we would use about .000025 of the total available IPv6 address space.
You are to be commended for your leadership in conserving space. Our children will surely be grateful that thanks to your efforts they have 99.99999% of IPv6 space left to work with rather than the paltry 99.9975% that might have been their inheritance were it not for your efforts. Bravo!
It makes a bigger difference if everyone starts using 6RD - to give out a /48 effectively requires a /16, and the number of /16s is by no means approximately infinite.
That is why the AC chose to allow for a /56 per end-site in the transitional technology policy (6rd is a transitional technology) and why we call for them to be issued from a distinct prefix separate from native IPv6 deployments. In this way, 6rd can be deployed sooner rather than later, but, we have the ability to move forward to a cleaner native IPv6 deployment and deprecate 6rd when it is no longer needed. Owen
RS, On Oct 18, 2010, at 2:16 PM, Robert E. Seastrom wrote:
If we were to give a /48 to every human on the face of the planet, we would use about .000025 of the total available IPv6 address space.
Sure. I once did the math that suggested that even if you multiplied the current IPv4 consumption rate by 1000 and applied that consumption rate to IPv6 /48s, the 1/8th of the IPv6 address space used for global unicast would last over 100 years. The problem is that allocation policy depends on who shows up at RIR meetings. Marshall has pointed out the (potential) implications of that policy with respect to 6rd. My math didn't take 6rd into account. Simply, there is no finite resource that people can't figure out a way to waste in an insane fashion. Since IPv6 is a finite resource, I personally think it makes sense for folks to be reasonably conservative in assignment to customers. Regards, -drc
On Oct 18, 2010, at 6:25 PM, David Conrad wrote:
RS,
On Oct 18, 2010, at 2:16 PM, Robert E. Seastrom wrote:
If we were to give a /48 to every human on the face of the planet, we would use about .000025 of the total available IPv6 address space.
Sure. I once did the math that suggested that even if you multiplied the current IPv4 consumption rate by 1000 and applied that consumption rate to IPv6 /48s, the 1/8th of the IPv6 address space used for global unicast would last over 100 years.
The problem is that allocation policy depends on who shows up at RIR meetings. Marshall has pointed out the (potential) implications of that policy with respect to 6rd. My math didn't take 6rd into account.
Simply, there is no finite resource that people can't figure out a way to waste in an insane fashion. Since IPv6 is a finite resource, I personally think it makes sense for folks to be reasonably conservative in assignment to customers.
Regards, -drc
Agreed. /48 is reasonably conservative in native IPv6 deployments. 6rd cannot be done in a reasonably conservative fashion, so, we're kind of stuck with giving /24s to ISPs to give /56s to their customers and living with the consequences. Owen
On 10/18/2010 5:16 PM, Robert E. Seastrom wrote:
sthaug@nethelp.no writes:
I still haven't seen any good argument for why residential users need /48s. No, I don't think "that makes all the address assignments the same size" is a particularly relevant or convincing argument.
We're doing /56 for residential users, and have no plans to change this.
If we were to give a /48 to every human on the face of the planet, we would use about .000025 of the total available IPv6 address space.
I'm confused. The "hand out /48s everywhere" crowd keeps saying that we need to do that because we haven't yet anticipated everything that end users might want to do with a /48 on their CPE. On the wider issue of "we don't yet understand everything that can be done with the space" I think we're in agreement. However my conclusion is that "therefore we should be careful to preserve the maximum flexibility possible." After we have some operational experience with IPv6 we will be in a position to make better decisions; but we have to GET operational experience first. Grousing about lack of adherence to holy writ in that deployment doesn't help anybody. And now I'm repeating myself, so that's all for tonight ... Doug -- Breadth of IT experience, and | Nothin' ever doesn't change, depth of knowledge in the DNS. | but nothin' changes much. Yours for the right price. :) | -- OK Go http://SupersetSolutions.com/
On Oct 18, 2010, at 7:24 PM, Doug Barton wrote:
On 10/18/2010 5:16 PM, Robert E. Seastrom wrote:
sthaug@nethelp.no writes:
I still haven't seen any good argument for why residential users need /48s. No, I don't think "that makes all the address assignments the same size" is a particularly relevant or convincing argument.
We're doing /56 for residential users, and have no plans to change this.
If we were to give a /48 to every human on the face of the planet, we would use about .000025 of the total available IPv6 address space.
I'm confused. The "hand out /48s everywhere" crowd keeps saying that we need to do that because we haven't yet anticipated everything that end users might want to do with a /48 on their CPE. On the wider issue of "we don't yet understand everything that can be done with the space" I think we're in agreement. However my conclusion is that "therefore we should be careful to preserve the maximum flexibility possible."
Right... Giving /48s to end users for native IPv6 deployments still preserves 99.9975% (or more) of the IPv6 space while not stifling innovation on the CPE side. Maximum flexibility is preserved on both sides of the ISP/customer boundary. Giving customers less doesn't really increase meaningful flexibility for the providers, it just keeps more address space on the shelf gathering dust.
After we have some operational experience with IPv6 we will be in a position to make better decisions; but we have to GET operational experience first. Grousing about lack of adherence to holy writ in that deployment doesn't help anybody.
Some of us actually have some operational experience with IPv6. As such, I'm not grousing about holy writ, I'm talking about real consequences of real actions in real world implementations. Owen
On 18/10/10Ā 19:24Ā -0700, Doug Barton wrote:
On 10/18/2010 5:16 PM, Robert E. Seastrom wrote:
sthaug@nethelp.no writes:
I still haven't seen any good argument for why residential users need /48s. No, I don't think "that makes all the address assignments the same size" is a particularly relevant or convincing argument.
We're doing /56 for residential users, and have no plans to change this.
If we were to give a /48 to every human on the face of the planet, we would use about .000025 of the total available IPv6 address space.
I'm confused. The "hand out /48s everywhere" crowd keeps saying that we need to do that because we haven't yet anticipated everything that end users might want to do with a /48 on their CPE. On the wider issue of "we don't yet understand everything that can be done with the space" I think we're in agreement. However my conclusion is that "therefore we should be careful to preserve the maximum flexibility possible."
After we have some operational experience with IPv6 we will be in a position to make better decisions; but we have to GET operational experience first. Grousing about lack of adherence to holy writ in that deployment doesn't help anybody.
I agree with you, but have come to a different conclusion. I would fall under the /48s crowd, except that I'm not really interested in an attempt to standardize /48 deployments. But I still feel strongly that a /48 assignment model for residential customers is right for our environment. With v4 assignments, we have a different philosophy. When we received our v4 assignments from ARIN, is was natural for us to take a conservative approach when handing out addresses... by default we assign one dynamic address to each customer and provide one or more static addresses for a nominal fee to customers, not because we want to make money from it, but because we want to be good stewards of those addresses. That's our 'fail safe' approach to v4 distribution (1 per customer). With v6, our 'fail safe' approach, without strong operational experience, is to assign larger blocks rather than smaller. A cycle in our staff in 5 or 10 years is likely to appreciate that decision, and we can't really justify a /56-rather-than-/48 decision based on address constraints. We really do have the addresses to support /48 deployments for the foreseeable future, and would expect future staff to request more addresses when they're needed. -- Dan White
On 10/19/2010 6:24 AM, Dan White wrote:
But I still feel strongly that a /48 assignment model for residential customers is right for our environment.
Perfectly reasonable. If you've analyzed your situation and come to that conclusion who am I to argue? Please note, I'm NOT saying, "You must use /56 for residential!" I'm saying that reasonable minds can differ, and that trying to jam everyone into the /48 mold does more harm than good. Doug -- Breadth of IT experience, and | Nothin' ever doesn't change, depth of knowledge in the DNS. | but nothin' changes much. Yours for the right price. :) | -- OK Go http://SupersetSolutions.com/
-----Original Message----- From: Robert E. Seastrom Sent: Monday, October 18, 2010 5:17 PM To: sthaug@nethelp.no Cc: nanog@nanog.org Subject: Re: Definitive Guide to IPv6 adoption
You are to be commended for your leadership in conserving space. Our children will surely be grateful that thanks to your efforts they have 99.99999% of IPv6 space left to work with rather than the paltry 99.9975% that might have been their inheritance were it not for your efforts. Bravo!
-r
I have a feeling that IP addresses will now be used in ways that people have not envisioned them being used before. Given a surplus of any resource, people find creative ways of using it.
On Mon, Oct 18, 2010 at 09:27:21PM -0700, George Bonser wrote:
I have a feeling that IP addresses will now be used in ways that people have not envisioned them being used before. Given a surplus of any resource, people find creative ways of using it.
Encoding high-resolution geographic coordinates, for multiple bodies in the solar system.
-----Original Message----- From: Eugen Leitl Sent: Tuesday, October 19, 2010 1:18 AM To: nanog@nanog.org Subject: Re: Definitive Guide to IPv6 adoption
On Mon, Oct 18, 2010 at 09:27:21PM -0700, George Bonser wrote:
I have a feeling that IP addresses will now be used in ways that people have not envisioned them being used before. Given a surplus of any resource, people find creative ways of using it.
Encoding high-resolution geographic coordinates, for multiple bodies in the solar system.
I was thinking more along the lines of dynamic IP assignment on server hosts and mapping client 64-bit GUIDs to ip addresses for directing traffic to the host with the client state information.
"George Bonser" <gbonser@seven.com> writes:
You are to be commended for your leadership in conserving space. Our children will surely be grateful that thanks to your efforts they have 99.99999% of IPv6 space left to work with rather than the paltry 99.9975% that might have been their inheritance were it not for your efforts. Bravo!
I have a feeling that IP addresses will now be used in ways that people have not envisioned them being used before. Given a surplus of any resource, people find creative ways of using it.
Which just reinforces the argument that we ought to give people /48s rather than /56es, /60s, or /64s even though those with a failure of imagination may not be able to figure out a reason anyone would need that much space. -r
Hi, Another way of looking at it would be what would the world population need to be in order to exhaust all of the space v6 based on /48s /56s or /64s per head / household - and is this population number ever going to happen in what time conceivable time frame. Another interesting calculation would be to divide the land mass area by that population figure - let alone the habital area. 2 to 48 = 281,474,976,710,658 or 280K Billion separate /48s assignments. (Current world population 6.7 Billion forecast 14 Billion in 2100) World Landmass (Total All Areas): 148.94 million sq km So Each Person at the point of IPv6 exhaustion will have 0.53 sq meters to stand on while using all their IPv6 devices. I think it is safe to say that the world will be facing other more significant problems long long long before we get anywhere near having to worry about running out of IPv6 space because we are assigning each individual a /48. There are surely technical benefits from a routing perspective if all the end user assignments are the same size - therefore should the technical considerations here not override any argument about conservation of space seeing as the above hopefully proves the fallacy of needing to conserve IPv6 address space???? Ben -----Original Message----- From: Robert E. Seastrom [mailto:rs@seastrom.com] Sent: 19 October 2010 11:53 To: George Bonser Cc: nanog@nanog.org Subject: Re: Definitive Guide to IPv6 adoption "George Bonser" <gbonser@seven.com> writes:
You are to be commended for your leadership in conserving space. Our children will surely be grateful that thanks to your efforts they have 99.99999% of IPv6 space left to work with rather than the paltry 99.9975% that might have been their inheritance were it not for your efforts. Bravo!
I have a feeling that IP addresses will now be used in ways that people have not envisioned them being used before. Given a surplus of any resource, people find creative ways of using it.
Which just reinforces the argument that we ought to give people /48s rather than /56es, /60s, or /64s even though those with a failure of imagination may not be able to figure out a reason anyone would need that much space. -r -------------------------------------------------------------------------- BODY { MARGIN: 0px}.footerdark { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #001a35; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.blackcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.bluecopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #29aae2; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.address { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; TEXT-DECORATION: none}.footerlight { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #667891; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.pinkcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #ed174d; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none} Ben Butler Director Tel: 0333 666 3332 Fax: 0333 666 3331 C2 Business Networking Ltd The Paddock, London Road, Nantwich, Cheshire, CW5 7JL http://www.c2internet.net/ Part of the Atlas Business Group of Companies plc Registered in England: 07102986 Registered Address: Datum House, Electra Way, Crewe CW1 6ZF Vat Registration No: 712 9503 48 This message is confidential and intended for the use only of the person to whom it is addressed. If you are not the intended recipient you are strictly prohibited from reading, disseminating, copying, printing, re-transmitting or using this message or its contents in any way. Opinions, conclusions and other information expressed in this message are not given or authorised by the Company unless otherwise indicated by an authorised representative independent of this message. The Company does not accept liability for any data corruption, interception or amendment to any e-mail or the consequences thereof.Emails addressed to individuals may not necessarily be read by that person unless they are in the office.Calls to and from any of the Atlas Business Group of Companies may be recorded for the purposes of training, monitoring of quality and customer services.
Hi, Maybe we should reserve the first couple of bits to serve as a planet identifier, so that once we have colonized the heavens Star Trek Federation style we can route to all of those Billions of life forms. Routing convergence times shouldnāt be too much of an issue even with light version 1 (while we wait for FTL transport mechanisms) as I suspect there wont be too many interplanetary transit providers to have worry about in the routing mesh. But again in all seriousness - surely this is a problem for the distant future (sadly and Stephen Hawking would agree about our species' need for colonization to ensure survival) and in the meantime we just get on as quickly as possible with getting IPv6 rolled out and adhering to standards of how we do it so we don't create yet another inconsistent mess with everyone following different "standard" best practices. Ben -----Original Message----- From: Ben Butler [mailto:ben.butler@c2internet.net] Sent: 19 October 2010 12:26 To: nanog@nanog.org Subject: RE: Definitive Guide to IPv6 adoption Hi, Another way of looking at it would be what would the world population need to be in order to exhaust all of the space v6 based on /48s /56s or /64s per head / household - and is this population number ever going to happen in what time conceivable time frame. Another interesting calculation would be to divide the land mass area by that population figure - let alone the habital area. 2 to 48 = 281,474,976,710,658 or 280K Billion separate /48s assignments. (Current world population 6.7 Billion forecast 14 Billion in 2100) World Landmass (Total All Areas): 148.94 million sq km So Each Person at the point of IPv6 exhaustion will have 0.53 sq meters to stand on while using all their IPv6 devices. I think it is safe to say that the world will be facing other more significant problems long long long before we get anywhere near having to worry about running out of IPv6 space because we are assigning each individual a /48. There are surely technical benefits from a routing perspective if all the end user assignments are the same size - therefore should the technical considerations here not override any argument about conservation of space seeing as the above hopefully proves the fallacy of needing to conserve IPv6 address space???? Ben -----Original Message----- From: Robert E. Seastrom [mailto:rs@seastrom.com] Sent: 19 October 2010 11:53 To: George Bonser Cc: nanog@nanog.org Subject: Re: Definitive Guide to IPv6 adoption "George Bonser" <gbonser@seven.com> writes:
You are to be commended for your leadership in conserving space. Our children will surely be grateful that thanks to your efforts they have 99.99999% of IPv6 space left to work with rather than the paltry 99.9975% that might have been their inheritance were it not for your efforts. Bravo!
I have a feeling that IP addresses will now be used in ways that people have not envisioned them being used before. Given a surplus of any resource, people find creative ways of using it.
Which just reinforces the argument that we ought to give people /48s rather than /56es, /60s, or /64s even though those with a failure of imagination may not be able to figure out a reason anyone would need that much space. -r -------------------------------------------------------------------------- BODY { MARGIN: 0px}.footerdark { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #001a35; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.blackcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.bluecopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #29aae2; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.address { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; TEXT-DECORATION: none}.footerlight { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #667891; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.pinkcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #ed174d; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none} Ben Butler Director Tel: 0333 666 3332 Fax: 0333 666 3331 C2 Business Networking Ltd The Paddock, London Road, Nantwich, Cheshire, CW5 7JL http://www.c2internet.net/ Part of the Atlas Business Group of Companies plc Registered in England: 07102986 Registered Address: Datum House, Electra Way, Crewe CW1 6ZF Vat Registration No: 712 9503 48 This message is confidential and intended for the use only of the person to whom it is addressed. If you are not the intended recipient you are strictly prohibited from reading, disseminating, copying, printing, re-transmitting or using this message or its contents in any way. Opinions, conclusions and other information expressed in this message are not given or authorised by the Company unless otherwise indicated by an authorised representative independent of this message. The Company does not accept liability for any data corruption, interception or amendment to any e-mail or the consequences thereof.Emails addressed to individuals may not necessarily be read by that person unless they are in the office.Calls to and from any of the Atlas Business Group of Companies may be recorded for the purposes of training, monitoring of quality and customer services.
On Oct 19, 2010, at 4:25 AM, Ben Butler wrote:
Hi,
Another way of looking at it would be what would the world population need to be in order to exhaust all of the space v6 based on /48s /56s or /64s per head / household - and is this population number ever going to happen in what time conceivable time frame.
Another interesting calculation would be to divide the land mass area by that population figure - let alone the habital area.
2 to 48 = 281,474,976,710,658 or 280K Billion separate /48s assignments.
(Current world population 6.7 Billion forecast 14 Billion in 2100)
World Landmass (Total All Areas): 148.94 million sq km
So Each Person at the point of IPv6 exhaustion will have 0.53 sq meters to stand on while using all their IPv6 devices.
I think it is safe to say that the world will be facing other more significant problems long long long before we get anywhere near having to worry about running out of IPv6 space because we are assigning each individual a /48.
This does, of course, assume that the population remains earthbound beyond 2100. I think that is not entirely likely.
There are surely technical benefits from a routing perspective if all the end user assignments are the same size - therefore should the technical considerations here not override any argument about conservation of space seeing as the above hopefully proves the fallacy of needing to conserve IPv6 address space????
Yes... The technical considerations should override silly efforts to keep more than 99.99% of all IPv6 space in reserve for some unprojected need since we have real projected needs for the 0.001% now. Owen
Ben
-----Original Message----- From: Robert E. Seastrom [mailto:rs@seastrom.com] Sent: 19 October 2010 11:53 To: George Bonser Cc: nanog@nanog.org Subject: Re: Definitive Guide to IPv6 adoption
"George Bonser" <gbonser@seven.com> writes:
You are to be commended for your leadership in conserving space. Our children will surely be grateful that thanks to your efforts they have 99.99999% of IPv6 space left to work with rather than the paltry 99.9975% that might have been their inheritance were it not for your efforts. Bravo!
I have a feeling that IP addresses will now be used in ways that people have not envisioned them being used before. Given a surplus of any resource, people find creative ways of using it.
Which just reinforces the argument that we ought to give people /48s rather than /56es, /60s, or /64s even though those with a failure of imagination may not be able to figure out a reason anyone would need that much space.
-r
-------------------------------------------------------------------------- BODY { MARGIN: 0px}.footerdark { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #001a35; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.blackcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.bluecopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #29aae2; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.address { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; TEXT-DECORATION: none}.footerlight { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #667891; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.pinkcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #ed174d; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none} Ben Butler Director Tel: 0333 666 3332 Fax: 0333 666 3331 C2 Business Networking Ltd The Paddock, London Road, Nantwich, Cheshire, CW5 7JL http://www.c2internet.net/
Part of the Atlas Business Group of Companies plc Registered in England: 07102986 Registered Address: Datum House, Electra Way, Crewe CW1 6ZF Vat Registration No: 712 9503 48 This message is confidential and intended for the use only of the person to whom it is addressed. If you are not the intended recipient you are strictly prohibited from reading, disseminating, copying, printing, re-transmitting or using this message or its contents in any way. Opinions, conclusions and other information expressed in this message are not given or authorised by the Company unless otherwise indicated by an authorised representative independent of this message. The Company does not accept liability for any data corruption, interception or amendment to any e-mail or the consequences thereof.Emails addressed to individuals may not necessarily be read by that person unless they are in the office.Calls to and from any of the Atlas Business Group of Companies may be recorded for the purposes of training, monitoring of quality and customer services.
On 10/18/2010 7:16 PM, Robert E. Seastrom wrote:
You are to be commended for your leadership in conserving space. Our children will surely be grateful that thanks to your efforts they have 99.99999% of IPv6 space left to work with rather than the paltry 99.9975% that might have been their inheritance were it not for your efforts. Bravo!
Thanks. Actually, I think people are following the RIR example. ARIN handed out a /32 as standard for an ISP, so a /32 is the framework even a medium sized ISP will use. Our routing/IP Numbering Plan: <regional assignment><pop assignment><customer assignment> /40 regional assignment supporting 256 regional assignments /44 for only 16 pop assignments? /48 to customer for only 16 customers per pop assignment? Perhaps another view /40 regional assignment supporting 256 regional assignments /44 still for 16 pop assignments /56 to customer for 4096 customer assignments I'm sorry, but I just couldn't find a way to make /48 to customers work appropriately, and ARIN seems to think a /32 is fair, yet I have to design an IP assignment plan up front to make for more efficient routing. I actually expect a /42-/43 per pop, and /38 per region even in the /56 to customer model. Jack
On Oct 18, 2010, at 10:53 PM, Jack Bates wrote:
On 10/18/2010 7:16 PM, Robert E. Seastrom wrote:
You are to be commended for your leadership in conserving space. Our children will surely be grateful that thanks to your efforts they have 99.99999% of IPv6 space left to work with rather than the paltry 99.9975% that might have been their inheritance were it not for your efforts. Bravo!
Thanks. Actually, I think people are following the RIR example. ARIN handed out a /32 as standard for an ISP, so a /32 is the framework even a medium sized ISP will use.
No... ARIN hands out a MINIMUM /32. A medium sized ISP should be asking for larger.
Our routing/IP Numbering Plan: <regional assignment><pop assignment><customer assignment>
/40 regional assignment supporting 256 regional assignments /44 for only 16 pop assignments? /48 to customer for only 16 customers per pop assignment?
Or, better...If you're that large... Start with a /28 /36 regional assignment supporting 256 regional assignments /40 for 16 pops per region /48 for 256 customer end-sites per POP or, if you have larger POPs, start with a /24 and /32 regional assignment supporting 256 regional assignments /36 for 16 pops per region /48 for 4,096 customer end-sites per POP or, if you have larger regions and more POPs per region /28 regional assignment supporting 16 regions /36 for 256 pops per region /48 for 4,096 customer end-sites per POP
Perhaps another view
/40 regional assignment supporting 256 regional assignments /44 still for 16 pop assignments /56 to customer for 4096 customer assignments
I'm sorry, but I just couldn't find a way to make /48 to customers work appropriately, and ARIN seems to think a /32 is fair, yet I have to design an IP assignment plan up front to make for more efficient routing. I actually expect a /42-/43 per pop, and /38 per region even in the /56 to customer model.
ARIN thinks a /32 is the MINIMUM for an ISP. Not the Maximum. Several ISPs have received larger than /32 and all you need to do is show a reasonable justification for the space. Owen
On 10/19/2010 4:29 AM, Owen DeLong wrote:
No... ARIN hands out a MINIMUM /32. A medium sized ISP should be asking for larger.
ME: I really need larger space ARIN: We don't see how you can justify it, and we hardly ever give larger than /32 THE END
or, if you have larger POPs, start with a /24 and /32 regional assignment supporting 256 regional assignments /36 for 16 pops per region /48 for 4,096 customer end-sites per POP
Ideal solution, but don't see it happening
ARIN thinks a /32 is the MINIMUM for an ISP. Not the Maximum. Several ISPs have received larger than /32 and all you need to do is show a reasonable justification for the space.
See above. You think I asked for a /32? While I'd probably desire a /24 for ease of routing and management, I'd only asked for a /31 and was turned down with the "Very few will get more than a /32." Hey, perhaps I'm wrong. Perhaps I asked too early, even though I purposefully delayed asking. and from your other reply:
Yep... Best not to argue with Jack... A much better strategy, IMHO, is to better serve his former customers.
Good luck on that. My customers like my service and the lengths we go for them. Obviously, there are always those who are discontent, but we listen to what they want and need, and we make it happen. Feel free to come to rural Oklahoma and compete. The prefix rotation argument has been covered before, which is why I'd rather keep it to the original argument and probably shouldn't have mentioned it since it always creates a side topic. Jack
On Oct 19, 2010, at 7:09 AM, Jack Bates wrote:
On 10/19/2010 4:29 AM, Owen DeLong wrote:
No... ARIN hands out a MINIMUM /32. A medium sized ISP should be asking for larger.
ME: I really need larger space ARIN: We don't see how you can justify it, and we hardly ever give larger than /32
Did you send them a customer count exceeding about 25,000 customers and point out that you were giving /48s to each of them? If you did, they would not have had a leg to stand on. However, there has been a bit of a learning curve with ARIN staff and IPv6, so, there have been some errant denials. I'm working on policy to further expand their ability to approve larger allocations. Expect to see it posted in the next week or so.
THE END
or, if you have larger POPs, start with a /24 and /32 regional assignment supporting 256 regional assignments /36 for 16 pops per region /48 for 4,096 customer end-sites per POP
Ideal solution, but don't see it happening
Why not?
ARIN thinks a /32 is the MINIMUM for an ISP. Not the Maximum. Several ISPs have received larger than /32 and all you need to do is show a reasonable justification for the space.
See above. You think I asked for a /32? While I'd probably desire a /24 for ease of routing and management, I'd only asked for a /31 and was turned down with the "Very few will get more than a /32."
When did you ask? If it was more than 6 months ago, then, I would suggest asking again. If it was less than 6 months ago, can you send me any or all of the correspondence so I can address it with Leslie and try and get whatever training issues remain resolved?
Hey, perhaps I'm wrong. Perhaps I asked too early, even though I purposefully delayed asking.
If ARIN is incorrectly denying requests, I'll definitely work on getting that resolved.
and from your other reply:
Yep... Best not to argue with Jack... A much better strategy, IMHO, is to better serve his former customers.
Good luck on that. My customers like my service and the lengths we go for them. Obviously, there are always those who are discontent, but we listen to what they want and need, and we make it happen. Feel free to come to rural Oklahoma and compete. The prefix rotation argument has been covered before, which is why I'd rather keep it to the original argument and probably shouldn't have mentioned it since it always creates a side topic.
The beauty is that we don't have to come to rural OK to compete. We can just let them use whatever stingy amount of address space you provide to get a tunnel to us. Owen
On 10/19/2010 1:21 PM, Owen DeLong wrote:
When did you ask? If it was more than 6 months ago, then, I would suggest asking again. If it was less than 6 months ago, can you send me any or all of the correspondence so I can address it with Leslie and try and get whatever training issues remain resolved?
RegDate: 2009-01-16 Haven't read anything on changes in the announcements, except the "we're sending this to PPML (think that's right?)", but no announcement on a change of opinion/policy. I have enough mailing lists.
If ARIN is incorrectly denying requests, I'll definitely work on getting that resolved.
We'll see. I've asked for a do-over, or whatever they called it. /24 seemed a bit much, so I slimmed down to /27, thinking it more appropriate for a 5 year plan (which is what they asked).
The beauty is that we don't have to come to rural OK to compete. We can just let them use whatever stingy amount of address space you provide to get a tunnel to us.
Sure they'll love the latency. I know I currently do with the mess that is core routing. Anyone who would actually care, probably would request a static, which we are much more lenient with IPv6 than IPv4. However, I can't issue /48 to everyone as things stand. We'll see how it goes with ARIN, now that I know I can ask again and not go through the hassle for nothing. Jack
Quick FYI - ARIN has a documented appeals process that an organization can use if they believe that ARIN staff did not follow community-established policies in the review of their resource request. Here is the link: https://www.arin.net/resources/resource_requests/appeal_process.html Regards, Leslie Leslie Nobile Director, Registration Services American Registry for Internet Numbers On 10/19/10 2:21 PM, "Owen DeLong" <owen@delong.com> wrote:
On Oct 19, 2010, at 7:09 AM, Jack Bates wrote:
On 10/19/2010 4:29 AM, Owen DeLong wrote:
No... ARIN hands out a MINIMUM /32. A medium sized ISP should be asking for larger.
ME: I really need larger space ARIN: We don't see how you can justify it, and we hardly ever give larger than /32
Did you send them a customer count exceeding about 25,000 customers and point out that you were giving /48s to each of them? If you did, they would not have had a leg to stand on.
However, there has been a bit of a learning curve with ARIN staff and IPv6, so, there have been some errant denials. I'm working on policy to further expand their ability to approve larger allocations. Expect to see it posted in the next week or so.
THE END
or, if you have larger POPs, start with a /24 and /32 regional assignment supporting 256 regional assignments /36 for 16 pops per region /48 for 4,096 customer end-sites per POP
Ideal solution, but don't see it happening
Why not?
ARIN thinks a /32 is the MINIMUM for an ISP. Not the Maximum. Several ISPs have received larger than /32 and all you need to do is show a reasonable justification for the space.
See above. You think I asked for a /32? While I'd probably desire a /24 for ease of routing and management, I'd only asked for a /31 and was turned down with the "Very few will get more than a /32."
When did you ask? If it was more than 6 months ago, then, I would suggest asking again. If it was less than 6 months ago, can you send me any or all of the correspondence so I can address it with Leslie and try and get whatever training issues remain resolved?
Hey, perhaps I'm wrong. Perhaps I asked too early, even though I purposefully delayed asking.
If ARIN is incorrectly denying requests, I'll definitely work on getting that resolved.
and from your other reply:
Yep... Best not to argue with Jack... A much better strategy, IMHO, is to better serve his former customers.
Good luck on that. My customers like my service and the lengths we go for them. Obviously, there are always those who are discontent, but we listen to what they want and need, and we make it happen. Feel free to come to rural Oklahoma and compete. The prefix rotation argument has been covered before, which is why I'd rather keep it to the original argument and probably shouldn't have mentioned it since it always creates a side topic.
The beauty is that we don't have to come to rural OK to compete. We can just let them use whatever stingy amount of address space you provide to get a tunnel to us.
Owen
"Dobbins, Roland" <rdobbins@arbor.net> writes:
Eric Vyncke's IPv6 security book is definitely worthwhile,
<http://www.ciscopress.com/bookstore/product.asp?isbn=1587055945>
A good companion to Eric's book is Deploying IPv6 Networks <http://www.ciscopress.com/bookstore/product.asp?isbn=1587052105> Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink@guug.de | ------------------- | -------------------------------------------------------------------------
Date: Sun, 17 Oct 2010 00:40:41 +1030 From: Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org>
On Sat, 16 Oct 2010 12:31:22 +0100 Randy Bush <randy@psg.com> wrote:
http://www.ietf.org/internet-drafts/draft-ietf-6man-prefixlen-p2p-00.txt
Drafts are drafts, and nothing more, aren't they?
Drafts are drafts. Even most RFCs are RFCs and nothing more. Only a handful have ever been designated as "Standards". I hope this becomes one of those in the hope it will be taken seriously. (It already is by anyone with a large network running IPv6.) The point is to READ the draft arguments and see why /127s are the right way to address P2P circuits. Also, you might note the contributors to the draft. They are people well know on this list who have real, honest to goodness operational experience in running networks and really understand that a /64 on a P2P connection is a serious security problem. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
On Sat, 16 Oct 2010 15:26:54 -0700 "Kevin Oberman" <oberman@es.net> wrote:
Date: Sun, 17 Oct 2010 00:40:41 +1030 From: Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org>
On Sat, 16 Oct 2010 12:31:22 +0100 Randy Bush <randy@psg.com> wrote:
http://www.ietf.org/internet-drafts/draft-ietf-6man-prefixlen-p2p-00.txt
Drafts are drafts, and nothing more, aren't they?
Drafts are drafts. Even most RFCs are RFCs and nothing more.
No, drafts are documents that can be submitted by anybody, and can say anything, where as RFCs have been through an IETF evaluation process.
Only a handful have ever been designated as "Standards". I hope this becomes one of those in the hope it will be taken seriously. (It already is by anyone with a large network running IPv6.)
The point is to READ the draft arguments and see why /127s are the right way to address P2P circuits.
I suggest you search the v6ops mailing list, as I've read it multiple times, including all revisions, and have pointed out multiple issues with it.
Also, you might note the contributors to the draft. They are people well know on this list who have real, honest to goodness operational experience in running networks and really understand that a /64 on a P2P connection is a serious security problem.
As do I. You can see my analysis of the issue, and how I think it should be fixed properly, not mitigated for one type of link at the following URLs. http://www.ops.ietf.org/lists/v6ops/v6ops.2010/msg00543.html http://www.ietf.org/mail-archive/web/ipv6/current/msg12400.html
Date: Sun, 17 Oct 2010 10:24:41 +1030 From: Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org>
On Sat, 16 Oct 2010 15:26:54 -0700 "Kevin Oberman" <oberman@es.net> wrote:
Date: Sun, 17 Oct 2010 00:40:41 +1030 From: Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org>
On Sat, 16 Oct 2010 12:31:22 +0100 Randy Bush <randy@psg.com> wrote:
http://www.ietf.org/internet-drafts/draft-ietf-6man-prefixlen-p2p-00.txt
Drafts are drafts, and nothing more, aren't they?
Drafts are drafts. Even most RFCs are RFCs and nothing more.
No, drafts are documents that can be submitted by anybody, and can say anything, where as RFCs have been through an IETF evaluation process.
Only a handful have ever been designated as "Standards". I hope this becomes one of those in the hope it will be taken seriously. (It already is by anyone with a large network running IPv6.)
The point is to READ the draft arguments and see why /127s are the right way to address P2P circuits.
I suggest you search the v6ops mailing list, as I've read it multiple times, including all revisions, and have pointed out multiple issues with it.
Also, you might note the contributors to the draft. They are people well know on this list who have real, honest to goodness operational experience in running networks and really understand that a /64 on a P2P connection is a serious security problem.
As do I. You can see my analysis of the issue, and how I think it should be fixed properly, not mitigated for one type of link at the following URLs.
http://www.ops.ietf.org/lists/v6ops/v6ops.2010/msg00543.html
http://www.ietf.org/mail-archive/web/ipv6/current/msg12400.html
I don't entirely agree with your arguments, but the approach looks, at first glance, to be quite interesting and could quite possibly fix the problem. I'll need to digest it a bit better. Have you or someone else authored a draft on this proposal? In the meantime, I still support /127s for P2P links. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Hi Kevin, On Sat, 16 Oct 2010 20:13:22 -0700 "Kevin Oberman" <oberman@es.net> wrote:
Date: Sun, 17 Oct 2010 10:24:41 +1030 From: Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org>
On Sat, 16 Oct 2010 15:26:54 -0700 "Kevin Oberman" <oberman@es.net> wrote:
Date: Sun, 17 Oct 2010 00:40:41 +1030 From: Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org>
On Sat, 16 Oct 2010 12:31:22 +0100 Randy Bush <randy@psg.com> wrote:
http://www.ietf.org/internet-drafts/draft-ietf-6man-prefixlen-p2p-00.txt
Drafts are drafts, and nothing more, aren't they?
Drafts are drafts. Even most RFCs are RFCs and nothing more.
No, drafts are documents that can be submitted by anybody, and can say anything, where as RFCs have been through an IETF evaluation process.
Only a handful have ever been designated as "Standards". I hope this becomes one of those in the hope it will be taken seriously. (It already is by anyone with a large network running IPv6.)
The point is to READ the draft arguments and see why /127s are the right way to address P2P circuits.
I suggest you search the v6ops mailing list, as I've read it multiple times, including all revisions, and have pointed out multiple issues with it.
Also, you might note the contributors to the draft. They are people well know on this list who have real, honest to goodness operational experience in running networks and really understand that a /64 on a P2P connection is a serious security problem.
As do I. You can see my analysis of the issue, and how I think it should be fixed properly, not mitigated for one type of link at the following URLs.
http://www.ops.ietf.org/lists/v6ops/v6ops.2010/msg00543.html
http://www.ietf.org/mail-archive/web/ipv6/current/msg12400.html
I don't entirely agree with your arguments, but the approach looks, at first glance, to be quite interesting and could quite possibly fix the problem. I'll need to digest it a bit better.
Have you or someone else authored a draft on this proposal?
I've started writing one on the nonce solution, as it can be made to interoperate with existing deployed ND NS/NA mechanisms. Regards, Mark.
In the meantime, I still support /127s for P2P links. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
http://www.ietf.org/internet-drafts/draft-ietf-6man-prefixlen-p2p-00.txt Drafts are drafts, and nothing more, aren't they?
must be some blowhard i have plonked
Drafts are drafts. Even most RFCs are RFCs and nothing more. Only a handful have ever been designated as "Standards". I hope this becomes one of those in the hope it will be taken seriously. (It already is by anyone with a large network running IPv6.)
juniper and cisco implement today randy
Date: Sun, 17 Oct 2010 01:56:28 +0100 From: Randy Bush <randy@psg.com>
http://www.ietf.org/internet-drafts/draft-ietf-6man-prefixlen-p2p-00.txt Drafts are drafts, and nothing more, aren't they?
must be some blowhard i have plonked
Drafts are drafts. Even most RFCs are RFCs and nothing more. Only a handful have ever been designated as "Standards". I hope this becomes one of those in the hope it will be taken seriously. (It already is by anyone with a large network running IPv6.)
juniper and cisco implement today
Unfortunately, a couple of other router vendors whose top of the line units I have tested recently did not. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
On Oct 16, 2010, at 10:55 PM, Kevin Oberman wrote:
Date: Sun, 17 Oct 2010 01:56:28 +0100 From: Randy Bush <randy@psg.com>
http://www.ietf.org/internet-drafts/draft-ietf-6man-prefixlen-p2p-00.txt Drafts are drafts, and nothing more, aren't they?
must be some blowhard i have plonked
Drafts are drafts. Even most RFCs are RFCs and nothing more. Only a handful have ever been designated as "Standards". I hope this becomes one of those in the hope it will be taken seriously. (It already is by anyone with a large network running IPv6.)
juniper and cisco implement today
Unfortunately, a couple of other router vendors whose top of the line units I have tested recently did not.
Simple Matter of Programming ;-) Please suggest to said vendors that they implement this -- IMO it's the right way to do it... W
-- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
From: Warren Kumari <warren@kumari.net> Date: Sun, 17 Oct 2010 22:07:53 -0400
On Oct 16, 2010, at 10:55 PM, Kevin Oberman wrote:
Date: Sun, 17 Oct 2010 01:56:28 +0100 From: Randy Bush <randy@psg.com>
http://www.ietf.org/internet-drafts/draft-ietf-6man-prefixlen-p2p-00.txt Drafts are drafts, and nothing more, aren't they?
must be some blowhard i have plonked
Drafts are drafts. Even most RFCs are RFCs and nothing more. Only a handful have ever been designated as "Standards". I hope this becomes one of those in the hope it will be taken seriously. (It already is by anyone with a large network running IPv6.)
juniper and cisco implement today
Unfortunately, a couple of other router vendors whose top of the line units I have tested recently did not.
Simple Matter of Programming ;-)
Please suggest to said vendors that they implement this -- IMO it's the right way to do it...
Rest assured that I did so during the debrief on our evaluation. I know one promised a fix quickly. I don't recall on the other as that problem was not very significant compared to other issues with that unit. These evals are so much fun. I had to listen to a sales type explain that mBGP was incomplete for MY benefit. It might confuse me to be able to run multiple address families over a single peering session. I am so touched for this sort of concern. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
participants (34)
-
Ben Butler -
Brandon Kim -
Dan White -
David Conrad -
Dobbins, Roland -
Doug Barton -
Eugen Leitl -
Franck Martin -
George Bonser -
Jack Bates -
Jens Link -
Jeroen Massar -
Joel Jaeggli -
John Curran -
Jon Lewis -
Kevin Oberman -
Lee -
Leslie Nobile -
Mark Andrews -
Mark Smith -
Marshall Eubanks -
Nick Hilliard -
Owen DeLong -
Randy Bush -
Randy Carpenter -
Robert E. Seastrom -
Schiller, Heather A (HeatherSkanks) -
Scott Howard -
Seth Mattinen -
sthaugļ¼ nethelp.no -
Tony Finch -
Tony Hain -
Warren Kumari -
Zaid Ali