Keyboard Shortcuts
Thread View
j: Next unread messagek: Previous unread messagej a: Jump to all threadsj l: Jump to MailingList overview
On Sunday, September 18, 2011 01:43:13 AM Owen DeLong wrote:
Multiple prefix sizes, address fragmentation, etc. Admittedly, it's a small complication, but, it is a complication.
Further, it violates the principle of least surprise as your organization scales and brings in new engineers.
A good v6 address assignment policy for one's infrastructure is neither difficult to create nor maintain.
No issues here since we started running v6 over 6 years ago. We know how v6 can make address management within an ISP's network brain-dead to maintain, but it's not reason enough to use /64's where we can comfortably use /112's and still not overly complicate our lives.
So did I. I was being a little tongue in cheek/snarky with just presenting the math on the number of addresses,...
I know what you were getting at, with multiple v6 addresses on a single interface, e.t.c.
but the reality is that there may be some cases where having multiple addresses for one end of a point to point or the other (or both) may prove useful. These are admittedly rare.
Agree, but having run multiple networks with v6 over the last several years, we're yet to find with a reason that has required us to have multiple addresses on point-to-point links either between infrastructure, or between AS domains. Some things really are that simple :-).
Obviously, I can't speak for anyone else's network, just ours.
Mark.
Attachments:
- signature.asc (application/pgp-signature — 836 bytes)
Ditto Mark -
And I tend to disagree that if IPv6 did not have autoconfiguration feature, then IPv6 would have been devised with only 64 bits ?? It does not make sense coz then you are only increasing 32 bits more to the current size of the IP which IMO would not have been a significant increase in the IP size. IMO IPv6 was devised with 128 bits and was meant to address infinitely large number of hosts so that we never run out of addresses - and autoconfiguration etc were features added to IPv6 protocol later to make addressing easy. I see autoconfiguration as a feature only and nothing more than that. RFC 4291 does not pose any restriction or requirement on the IPv6 address assignment architecture that every subnet should or must be /64 or /48 etc and why it cannot be a /112 or something smaller.
________________________________ From: Mark Tinka mtinka@globaltransit.net To: Owen DeLong owen@delong.com Cc: Skeeve Stevens Skeeve@eintellego.net; sig-policy@lists.apnic.net Sent: Sunday, 18 September 2011 4:02 AM Subject: Re: [sig-policy] Need to understand logic behind assigning /64 IPv6 addresses
On Sunday, September 18, 2011 01:43:13 AM Owen DeLong wrote:
Multiple prefix sizes, address fragmentation, etc. Admittedly, it's a small complication, but, it is a complication.
Further, it violates the principle of least surprise as your organization scales and brings in new engineers.
A good v6 address assignment policy for one's infrastructure is neither difficult to create nor maintain.
No issues here since we started running v6 over 6 years ago. We know how v6 can make address management within an ISP's network brain-dead to maintain, but it's not reason enough to use /64's where we can comfortably use /112's and still not overly complicate our lives.
So did I. I was being a little tongue in cheek/snarky with just presenting the math on the number of addresses,...
I know what you were getting at, with multiple v6 addresses on a single interface, e.t.c.
but the reality is that there may be some cases where having multiple addresses for one end of a point to point or the other (or both) may prove useful. These are admittedly rare.
Agree, but having run multiple networks with v6 over the last several years, we're yet to find with a reason that has required us to have multiple addresses on point-to-point links either between infrastructure, or between AS domains. Some things really are that simple :-).
Obviously, I can't speak for anyone else's network, just ours.
Mark.
* sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Sent from my iPad
On Sep 17, 2011, at 14:42, Usman Latif osmankh@yahoo.com wrote:
Ditto Mark -
And I tend to disagree that if IPv6 did not have autoconfiguration feature, then IPv6 would have been devised with only 64 bits ?? It does not make sense coz then you are only increasing 32 bits more to the current size of the IP which IMO would not have been a significant increase in the IP size. IMO IPv6 was
It would have been a 4.2Billion x increase. You don't think that's significant? You and I have very different ideas of what constitutes a significant increase in size.
If you go back and review the records of the IETF from the time, you will find that the discussion centered largely around a 64 bit address space until the idea of stateless auto configuration was proposed and that it did, indeed, spur the idea to add another 64 bits to cover it.
devised with 128 bits and was meant to address infinitely large number of hosts so that we never run out of addresses - and autoconfiguration etc were features added to IPv6 protocol later to make addressing easy. I see autoconfiguration as a feature only and nothing more than that.
The history in the IETF mailing lists differs from your statement here.
RFC 4291 does not pose any restriction or requirement on the IPv6 address assignment architecture that every subnet should or must be /64 or /48 etc and why it cannot be a /112 or something smaller.
Correct. You can do whatever you want with your network. There are other places where /64, /48, and /32 are recommended and, IMHO, /64 per subnet, /48 per end site and minimum /32 per ISP are good starting points and current best common practice.
You are welcome to do otherwise, just as you are welcome to put sugar into your gas tank. However, being stingy with IPv6 resources will degrade the overall capability of your network(s) and possibly the internet, just as putting sugar in your gas tank will degrade the performance of your car.
Owen
From: Mark Tinka mtinka@globaltransit.net To: Owen DeLong owen@delong.com Cc: Skeeve Stevens Skeeve@eintellego.net; sig-policy@lists.apnic.net Sent: Sunday, 18 September 2011 4:02 AM Subject: Re: [sig-policy] Need to understand logic behind assigning /64 IPv6 addresses
On Sunday, September 18, 2011 01:43:13 AM Owen DeLong wrote:
Multiple prefix sizes, address fragmentation, etc. Admittedly, it's a small complication, but, it is a complication.
Further, it violates the principle of least surprise as your organization scales and brings in new engineers.
A good v6 address assignment policy for one's infrastructure is neither difficult to create nor maintain.
No issues here since we started running v6 over 6 years ago. We know how v6 can make address management within an ISP's network brain-dead to maintain, but it's not reason enough to use /64's where we can comfortably use /112's and still not overly complicate our lives.
So did I. I was being a little tongue in cheek/snarky with just presenting the math on the number of addresses,...
I know what you were getting at, with multiple v6 addresses on a single interface, e.t.c.
but the reality is that there may be some cases where having multiple addresses for one end of a point to point or the other (or both) may prove useful. These are admittedly rare.
Agree, but having run multiple networks with v6 over the last several years, we're yet to find with a reason that has required us to have multiple addresses on point-to-point links either between infrastructure, or between AS domains. Some things really are that simple :-).
Obviously, I can't speak for anyone else's network, just ours.
Mark.
sig-policy: APNIC SIG on resource management policy *
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
I sense the recommendations for /64 assignments even to residential users looks more political than technical.
It seems that because end-hosts and other systems have already been built with more support for stateless autoconfig, this may act as a roadblock for us.
First of all, the RFC-6177 does not give the reasoning behind suggesting /64 as being technically motivated but more from the perspective of growth and scalability - I for one am having a hard time imagining how a "residential site" can grow to such a length that it would need 2^64 address space. I quote from 6177:
"At the same time, it might be tempting to give home sites a single /64, since that is already significantly more address space compared with today's IPv4 practice. However, this precludes the expectation that even home sites will grow to support multiple subnets going forward. Hence, it is strongly intended that even home sites be given multiple subnets worth of space, by default. Hence, this document still recommends giving home sites significantly more than a single /64, but does not recommend that every home site be given a /48 either."
As regards stateless auto-configuration, one might argue that we have alternatives like RFC-3315 (DHCPv6) are also available but this may make the stateless implementation completely redundant (?)
________________________________ From: Owen DeLong owen@delong.com To: Usman Latif osmankh@yahoo.com Cc: "mtinka@globaltransit.net" mtinka@globaltransit.net; Skeeve Stevens Skeeve@eintellego.net; "sig-policy@lists.apnic.net" sig-policy@lists.apnic.net Sent: Sunday, 18 September 2011 8:25 AM Subject: Re: [sig-policy] Need to understand logic behind assigning /64 IPv6 addresses
Sent from my iPad
On Sep 17, 2011, at 14:42, Usman Latif osmankh@yahoo.com wrote:
Ditto Mark -
And I tend to disagree that if IPv6 did not have autoconfiguration feature, then IPv6 would have been devised with only 64 bits ?? It does not make sense coz then you are only increasing 32 bits more to the current size of the IP which IMO would not have been a significant increase in the IP size. IMO IPv6 was
It would have been a 4.2Billion x increase. You don't think that's significant? You and I have very different ideas of what constitutes a significant increase in size.
If you go back and review the records of the IETF from the time, you will find that the discussion centered largely around a 64 bit address space until the idea of stateless auto configuration was proposed and that it did, indeed, spur the idea to add another 64 bits to cover it.
devised with 128 bits and was meant to address infinitely large number of hosts so that we never run out of addresses - and autoconfiguration etc were features added to IPv6 protocol later to make addressing easy.
I see autoconfiguration as a feature only and nothing more than that.
The history in the IETF mailing lists differs from your statement here.
RFC 4291 does not pose any restriction or requirement on the IPv6 address assignment architecture that every subnet should or must be /64 or /48 etc and why it cannot be a /112 or something smaller.
Correct. You can do whatever you want with your network. There are other places where /64, /48, and /32 are recommended and, IMHO, /64 per subnet, /48 per end site and minimum /32 per ISP are good starting points and current best common practice.
You are welcome to do otherwise, just as you are welcome to put sugar into your gas tank. However, being stingy with IPv6 resources will degrade the overall capability of your network(s) and possibly the internet, just as putting sugar in your gas tank will degrade the performance of your car.
Owen
From: Mark Tinka mtinka@globaltransit.net To: Owen DeLong owen@delong.com Cc: Skeeve Stevens Skeeve@eintellego.net; sig-policy@lists.apnic.net Sent: Sunday, 18 September 2011 4:02 AM Subject: Re: [sig-policy] Need to understand logic behind assigning /64 IPv6 addresses
On Sunday, September 18, 2011 01:43:13 AM Owen DeLong wrote:
Multiple prefix
sizes, address fragmentation, etc.
Admittedly, it's a small complication, but, it is a complication.
Further, it violates the principle of least surprise as your organization scales and brings in new engineers.
A good v6 address assignment policy for one's infrastructure is neither difficult to create nor maintain.
No issues here since we started running v6 over 6 years ago. We know how v6 can make address management within an ISP's network brain-dead to maintain, but it's not reason enough to use /64's where we can comfortably use /112's and still not overly complicate our lives.
So did I. I was being a little tongue in cheek/snarky with just presenting the math on the number of addresses,...
I know what you were getting at, with multiple v6 addresses on a single interface, e.t.c.
but the reality is that there may be some
cases where having multiple addresses for one end of a
point to point or the other (or both) may prove useful. These are admittedly rare.
Agree, but having run multiple networks with v6 over the last several years, we're yet to find with a reason that has required us to have multiple addresses on point-to-point links either between infrastructure, or between AS domains. Some things really are that simple :-).
Obviously, I can't speak for anyone else's network, just ours.
Mark.
* sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
On Sunday, September 18, 2011 11:24:39 AM Usman Latif wrote:
I sense the recommendations for /64 assignments even to residential users looks more political than technical.
I think it's simpler than that, Usman :-).
Because SLAAC, today, is much more useful than DHCPv6 when it comes to acquiring a default gateway for your host, /64's makes sense because SLAAC will work only if an interface is assigned with a /64 address.
The day DHCPv6 gets the Default Router option implemented (along with much-needed DHCPv6 Snooping capability), you may begin to see flexibility in this area, whether it's good or bad.
It seems that because end-hosts and other systems have already been built with more support for stateless autoconfig, this may act as a roadblock for us.
DHCPv6 is now shipping in Mac OS X: Lion (10.7), which was one of the major OS's out there still lacking it. It's just that without a Router option in DHCPv6, widespread use in enterprise situations that prefer centralized address management is still limited.
First of all, the RFC-6177 does not give the reasoning behind suggesting /64 as being technically motivated but more from the perspective of growth and scalability - I for one am having a hard time imagining how a "residential site" can grow to such a length that it would need 2^64 address space. I quote from 6177:
The requirement for growth in home networks being supported by SLAAC, which in turn requires /64 prefix lengths on CPE home gateways, is implied by RFC 6177.
Things could be different if DHCPv6 becomes a viable alternative to SLAAC.
As regards stateless auto-configuration, one might argue that we have alternatives like RFC-3315 (DHCPv6) are also available but this may make the stateless implementation completely redundant (?)
If DHCPv6 actually becomes operationally similar to DHCPv4, I think we shall have 3 camps:
o those that prefer SLAAC + DHCPv4. o those that prefer SLAAC + DHCPv6. o those that prefer just DHCPv6.
Cheers,
Mark.
Mark - I do not see any relevance between SLAAC and getting information about "Default Router".The SLAAC is an extra feature as per RFC 4862.
On the other hand, default router can be discovered by using IPv6 ND as per RFC 4861.
So why do we think that until the draft (http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-default-router-00) gets mature enough, we cannot use DHCPv6 effectively for high-volume single-user customer scenarios?
So when folks say that "we need atleast /64 subnets for all sites (including residential single-user customers) because SLAAC would fail" then we should ask ourselves the question:
- Do we have alternatives to SLAAC? I'd say yes we do (DHCPv6 and ND)...
- Is SLAAC the reason we are wasting 18446744073709551616 worth of address space for residential sites? I'd say this is not a good enough reason...
But without going into an endless debate on this subject, I think we all have our own perspectives of looking at things and when I initially started my query "Need to understand logic behind /64 IPv6 addresses" - I can only say that I am only partially convinced and cannot convince myself with the reasoning provided so far that its worth wasting that much address space using a one-size-fit-all approach of /64 - especially as I said in the case of home-user CPEs etc.
Thanks everyone for your involvement and I hope IPv6 fulfills our addressing requirements for thousands of years to come ...... :)
Regards Usman Latif
________________________________ From: Mark Tinka mtinka@globaltransit.net To: Usman Latif osmankh@yahoo.com Cc: Owen DeLong owen@delong.com; Skeeve Stevens Skeeve@eintellego.net; "sig-policy@lists.apnic.net" sig-policy@lists.apnic.net Sent: Sunday, 18 September 2011 4:32 PM Subject: Re: [sig-policy] Need to understand logic behind assigning /64 IPv6 addresses
On Sunday, September 18, 2011 11:24:39 AM Usman Latif wrote:
I sense the recommendations for /64 assignments even to residential users looks more political than technical.
I think it's simpler than that, Usman :-).
Because SLAAC, today, is much more useful than DHCPv6 when it comes to acquiring a default gateway for your host, /64's makes sense because SLAAC will work only if an interface is assigned with a /64 address.
The day DHCPv6 gets the Default Router option implemented (along with much-needed DHCPv6 Snooping capability), you may begin to see flexibility in this area, whether it's good or bad.
It seems that because end-hosts and other systems have already been built with more support for stateless autoconfig, this may act as a roadblock for us.
DHCPv6 is now shipping in Mac OS X: Lion (10.7), which was one of the major OS's out there still lacking it. It's just that without a Router option in DHCPv6, widespread use in enterprise situations that prefer centralized address management is still limited.
First of all, the RFC-6177 does not give the reasoning behind suggesting /64 as being technically motivated but more from the perspective of growth and scalability - I for one am having a hard time imagining how a "residential site" can grow to such a length that it would need 2^64 address space. I quote from 6177:
The requirement for growth in home networks being supported by SLAAC, which in turn requires /64 prefix lengths on CPE home gateways, is implied by RFC 6177.
Things could be different if DHCPv6 becomes a viable alternative to SLAAC.
As regards stateless auto-configuration, one might argue that we have alternatives like RFC-3315 (DHCPv6) are also available but this may make the stateless implementation completely redundant (?)
If DHCPv6 actually becomes operationally similar to DHCPv4, I think we shall have 3 camps:
o those that prefer SLAAC + DHCPv4. o those that prefer SLAAC + DHCPv6. o those that prefer just DHCPv6.
Cheers,
Mark.
On 9/18/2011 4:25 AM, Usman Latif wrote:
So when folks say that "we need atleast /64 subnets for all sites (including residential single-user customers) because SLAAC would fail" then we should ask ourselves the question:
- Do we have alternatives to SLAAC?
I'd say yes we do (DHCPv6 and ND)...
- Is SLAAC the reason we are wasting 18446744073709551616 worth of
address space for residential sites? I'd say this is not a good enough reason...
In turn these questions have to be reframed as 'But can we afford to be prescriptive about how our customers want to address their networks, and what IPv6 stacks they will have to have in their home?'
While the /64 approach is driven by SLAAC, it's driven because of established devices and stacks, and that SLAAC was seen as a good approach for simple home networking.
By removing the ability for your customers to deploy their internal networks in a way that allows SLAAC to function, you are likely going to annoy them.
"Why does my gaming device not work when I use ISP-A but does when I take it to my friend who uses ISP-B?"
But without going into an endless debate on this subject, I think we all have our own perspectives of looking at things and when I initially started my query "Need to understand logic behind /64 IPv6 addresses" - I can only say that I am only partially convinced and cannot convince myself with the reasoning provided so far that its worth wasting that much address space using a one-size-fit-all approach of /64 - especially as I said in the case of home-user CPEs etc.
I think you will find many people are only partially convinced by /64s (and SLAAC), however it's not really practical to change things. It's been a long and hard road to get DHCPv6 operationally deployable.
aj
Fair enough. I think given the magnitude of address space, wastage becomes a secondary concern.
I guess when you have 281,474,976,710,656 number of /48 subnets available, you can probably afford to not care too much about being wasteful....
This may be a correct assumption so long as the current architectures of subnets residing behind a physical router device continue to hold - because the real surge would occur if virtualized hosts themselves become router devices and further require subnets to reside behind them.
If the above becomes the case, we could have problems...
________________________________ From: Alastair Johnson aj@sneep.net To: sig-policy@lists.apnic.net Sent: Sunday, 18 September 2011 9:51 PM Subject: Re: [sig-policy] Need to understand logic behind assigning /64 IPv6 addresses
On 9/18/2011 4:25 AM, Usman Latif wrote:
So when folks say that "we need atleast /64 subnets for all sites (including residential single-user customers) because SLAAC would fail" then we should ask ourselves the question:
- Do we have alternatives to SLAAC?
I'd say yes we do (DHCPv6 and ND)...
- Is SLAAC the reason we are wasting 18446744073709551616 worth of
address space for residential sites? I'd say this is not a good enough reason...
In turn these questions have to be reframed as 'But can we afford to be prescriptive about how our customers want to address their networks, and what IPv6 stacks they will have to have in their home?'
While the /64 approach is driven by SLAAC, it's driven because of established devices and stacks, and that SLAAC was seen as a good approach for simple home networking.
By removing the ability for your customers to deploy their internal networks in a way that allows SLAAC to function, you are likely going to annoy them.
"Why does my gaming device not work when I use ISP-A but does when I take it to my friend who uses ISP-B?"
But without going into an endless debate on this subject, I think we all have our own perspectives of looking at things and when I initially started my query "Need to understand logic behind /64 IPv6 addresses" - I can only say that I am only partially convinced and cannot convince myself with the reasoning provided so far that its worth wasting that much address space using a one-size-fit-all approach of /64 - especially as I said in the case of home-user CPEs etc.
I think you will find many people are only partially convinced by /64s (and SLAAC), however it's not really practical to change things. It's been a long and hard road to get DHCPv6 operationally deployable.
aj * sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
If the above becomes the case, we could have problems...
we *will* have a problem. no fixed sized address space has ever been sufficient, be it memory, IP space, phone numbers, ...
it is just that, in this case, i hope to retire first.
randy
On Sunday, September 18, 2011 09:27:43 PM Usman Latif wrote:
This may be a correct assumption so long as the current architectures of subnets residing behind a physical router device continue to hold - because the real surge would occur if virtualized hosts themselves become router devices and further require subnets to reside behind them.
If the above becomes the case, we could have problems...
And that's the point - there's just no way of knowing what will happen in the future (whether during our lifetime, or not) that may accelerate the use of v6 address space, as our projections are based on current trends today, which may not be applicable beyond us.
Of course, this is on the assumption that this protocol is expected to outlive many of us, something our children's children's children will be happy that we thought about. If we're, however, looking at a shorter time scale, all bets are off. But I digress :-)...
Mark.
On Sep 18, 2011, at 8:05 AM, Mark Tinka wrote:
On Sunday, September 18, 2011 09:27:43 PM Usman Latif wrote:
This may be a correct assumption so long as the current architectures of subnets residing behind a physical router device continue to hold - because the real surge would occur if virtualized hosts themselves become router devices and further require subnets to reside behind them.
There's really no problem there. It's unlikely a virtualized host would consume more than a /48 even with /64s per virtualized subnet behind it.
If the above becomes the case, we could have problems...
And that's the point - there's just no way of knowing what will happen in the future (whether during our lifetime, or not) that may accelerate the use of v6 address space, as our projections are based on current trends today, which may not be applicable beyond us.
True, but, that's why we have 512 /12s in the first /3 and I'm advocating that we see how it goes for 20 of them.
My bet is that we won't burn through even 20 of the /12s in the first 20-50 years of IPv6 deployment.
I believe that the scaling limit we will hit with the IPv6 protocol is not address space. I don't know what it will be, but, I predict that it will not be addressing.
Of course, this is on the assumption that this protocol is expected to outlive many of us, something our children's children's children will be happy that we thought about. If we're, however, looking at a shorter time scale, all bets are off. But I digress :-)...
I think a 50 year lifespan for a protocol is optimistic. I think that if we get 30-50 years out of IPv6, it will have had a good run.
IPv6 is not our first protocol swap-out and it won't be our last.
Owen
Gentlemen, I am one of the many Network Engineers/architects that are today on the verge of assigning IPv6 addressing in their core networks. I initiated a discussion on the use of /64 and /48 addresses in IPv6 and after some debate was convinced or atleast satisfied that for the near/distant future, using /48s and /64s isnt going to cause address depletion.
However, there is one point that I would like to open a debate on and really looking for some substantial reasoning and logic on.
And this point is: "What is the IETF / IANA / APNIC best-practice / recommendation for assigning IPv6 addressing to strictly point-to-point links where we know there will never be more than one device on each end of the link for the foreseeable future"
I have gone through some RFCs (RFC 4291, RFC 5375, RFC 3627, RFC 3177 / 6177 and RFC 6164)
As a network engineer with IPv4 and some IPv6 background, I am inclined to use /126 addressing on strictly point to point links - but after discussion with peers in the industry have learnt that the recommendations are to use /64
I want to know rationale behind using a /64 on strictly point-to-point links where we know there will never be more than one device on each end of the link?
To me using something like a /126 saves and eases the management / support of the p2p links and gives it more predictability and control. There are conflicting recommendations and are not giving me the right direction e.g.:
RFC 4291 states: "For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format." RFC 5375 states: "126-bit subnet prefixes are typically used for point-to-point links similar to a the IPv4 address-conservative /30 allocation for point-to-point links. The usage of this subnet address length does not lead to any considerations beyond those discussed earlier in this section, particularly those related to the 'u' and 'g' bits (see B.2.4.) ..... it is recommended to take the 'u' and 'g' bits into consideration and to make sure that there is no overlap with any of the following well-known addresses:
o Subnet Router Anycast Address
o Reserved Subnet Anycast Address
o Addresses used by Embedded-RP
o ISATAP Addresses" I guess what I am looking for is some guidelines on why using subnet length greater than /64 is discouraged and whether there is likelihood that any future implementation (of protocol stacks) of IPv6 could create problems for deployments where engineers/architects have chosen to implement /126 on strictly p2p links Regards Usman
--- On Sun, 18/9/11, Usman Latif osmankh@yahoo.com wrote:
From: Usman Latif osmankh@yahoo.com Subject: Re: [sig-policy] Need to understand logic behind assigning /64 IPv6 addresses To: "Alastair Johnson" aj@sneep.net, "sig-policy@lists.apnic.net" sig-policy@lists.apnic.net Received: Sunday, 18 September, 2011, 5:57 PM
Fair enough. I think given the magnitude of address space, wastage becomes a secondary concern.
I guess when you have 281,474,976,710,656 number of /48 subnets available, you can probably afford to not care too much about being wasteful....
This may be a correct assumption so long as the current architectures of subnets residing behind a physical router device continue to hold - because the real surge would occur if virtualized hosts themselves become router devices and further require subnets to reside behind them.
If the above becomes the case, we could have problems...
From: Alastair Johnson aj@sneep.net To: sig-policy@lists.apnic.net Sent: Sunday, 18 September 2011 9:51 PM Subject: Re: [sig-policy] Need to understand logic behind assigning /64 IPv6 addresses
On 9/18/2011 4:25 AM, Usman Latif wrote:
So when folks say that "we need atleast /64 subnets for all sites (including residential single-user customers) because SLAAC would fail" then we should ask ourselves the question:
- Do we have alternatives to SLAAC?
I'd say yes we do (DHCPv6 and ND)...
- Is SLAAC the reason we are wasting 18446744073709551616 worth of
address space for residential sites? I'd say this is not a good enough reason...
In turn these questions have to be reframed as 'But can we afford to be prescriptive about how our customers want to address their networks, and what IPv6 stacks they will have to have in their home?'
While the /64 approach is driven by SLAAC, it's driven because of established devices and stacks, and that SLAAC was seen as a good approach for simple home networking.
By removing the ability for your customers to deploy their internal networks in a way that allows SLAAC to function, you are likely going to annoy them.
"Why does my gaming device not work when I use ISP-A but does when I take it to my friend who uses ISP-B?"
But without going into an endless debate on this subject, I think we all have our own perspectives of looking at things and when I initially started my query "Need to understand logic behind /64 IPv6 addresses" - I can only say that I am only partially convinced and cannot convince myself with the reasoning provided so far that its worth wasting that much address space using a one-size-fit-all approach of /64 - especially as I said in the case of home-user CPEs etc.
I think you will find many people are only partially convinced by /64s (and SLAAC), however it's not really practical to change things. It's been a long and hard road to get DHCPv6 operationally deployable.
aj * sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Hi Usman,
Usman Latif said the following on 21/09/12 13:46 :
And this point is: "What is the IETF / IANA / APNIC best-practice / recommendation for assigning IPv6 addressing to strictly point-to-point links where we know there will never be more than one device on each end of the link for the foreseeable future"
I have gone through some RFCs (RFC 4291, RFC 5375, RFC 3627, RFC 3177 / 6177 and RFC 6164)
RFC 6164 should give you the guidance you need.
As a network engineer with IPv4 and some IPv6 background, I am inclined to use /126 addressing on strictly point to point links - but after discussion with peers in the industry have learnt that the recommendations are to use /64
I want to know rationale behind using a /64 on strictly point-to-point links where we know there will never be more than one device on each end of the link?
Perhaps ask your peers who recommended addressing a point to point link as a /64?
To me using something like a /126 saves and eases the management / support of the p2p links and gives it more predictability and control.
It certainly mirrors the /30 for point to point links in IPv4.
I guess what I am looking for is some guidelines on why using subnet length greater than /64 is discouraged and whether there is likelihood that any future implementation (of protocol stacks) of IPv6 could create problems for deployments where engineers/architects have chosen to implement /126 on strictly p2p links
The general guidelines I see most folks following now are to number a point-to-point link as a /127, but reserve the entire /64. You then avoid the ping-pong problem described in RFC6164, but avoid the possibility of being caught out by future developments by numbering all your point-to-point link sequentially as /127s (I've been there for IPv4 years ago - not pleasant).
Saying all the above, most operators I've seen are using /64s, /126s or /127s for point to point links (reserving the entire /64 for the link). The use of /127s is the most recent development, and is certainly what I've been doing in my IPv6 workshop labs in the last couple of years.
Hope this helps!
philip --
On Sunday, September 18, 2011 07:51:46 PM Alastair Johnson wrote:
I think you will find many people are only partially convinced by /64s (and SLAAC), however it's not really practical to change things.
And that really is the bottom line.
As unhappy as some of us may be about the current state of affairs, it's what we have now, and have no choice but to get deploying so we can work the kinks out, e.t.c.
It's been a long and hard road to get DHCPv6 operationally deployable.
The road is still long, but hopefully we're heading in the right direction. I expect market pressure to make DHCPv6 more operationally sensible as the rest of the Internet catches on.
Mark.
On Sunday, September 18, 2011 07:25:50 PM Usman Latif wrote:
So why do we think that until the draft (http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-defau lt-router-00) gets mature enough, we cannot use DHCPv6 effectively for high-volume single-user customer scenarios?
Because most networks using DHCPv4 today expect that when they turn on DHCPv6, it will work exactly the same. They won't want to understand why DHCPv6 is crippled today in certain key aspects, and they really shouldn't have to.
You're preaching to the choir, Usman :-).
Mark.
On Sep 17, 2011, at 8:24 PM, Usman Latif wrote:
I sense the recommendations for /64 assignments even to residential users looks more political than technical.
I don't think very many people are advocating giving such a small assignment to residential users. The smallest common practice I am aware of is /60s and most providers are doing at least /56. I still think /48 is better.
It seems that because end-hosts and other systems have already been built with more support for stateless autoconfig, this may act as a roadblock for us.
The protocol was designed with stateless autoconf in mind. I'm not sure why you insist on ignoring this fact.
First of all, the RFC-6177 does not give the reasoning behind suggesting /64 as being technically motivated but more from the perspective of growth and scalability - I for one am having a hard time imagining how a "residential site" can grow to such a length that it would need 2^64 address space. I quote from 6177:
You need a bigger imagination.
It's really not about dense packing the hosts into the /64 and actually having 18 quintillion hosts on a subnet. Of course, nobody would do that, it exceeds the practical scaling limits of the layer 2 topology.
However, it means that you don't have to worry about counting hosts. Every network has enough numbers available for every host.
"At the same time, it might be tempting to give home sites a single /64, since that is already significantly more address space compared with today's IPv4 practice. However, this precludes the expectation that even home sites will grow to support multiple subnets going forward. Hence, it is strongly intended that even home sites be given multiple subnets worth of space, by default. Hence, this document still recommends giving home sites significantly more than a single /64, but does not recommend that every home site be given a /48 either."
Yes… In other words, a /64 is too small for a home according to 6177. Admittedly, 6177 backed way off from the /48 recommendation for residential users, but, I believe that was caving to pressure from the IPv4-think crowd and not based on any real engineering data.
As regards stateless auto-configuration, one might argue that we have alternatives like RFC-3315 (DHCPv6) are also available but this may make the stateless implementation completely redundant (?)
Stateless autoconfiguration and DHCPv6 are both valid address auto-assignment mechanisms in IPv6. Each has its strengths and weaknesses. Each has applications it is well suited for and applications it is not at all well suited to.
Owen
From: Owen DeLong owen@delong.com To: Usman Latif osmankh@yahoo.com Cc: "mtinka@globaltransit.net" mtinka@globaltransit.net; Skeeve Stevens Skeeve@eintellego.net; "sig-policy@lists.apnic.net" sig-policy@lists.apnic.net Sent: Sunday, 18 September 2011 8:25 AM Subject: Re: [sig-policy] Need to understand logic behind assigning /64 IPv6 addresses
Sent from my iPad
On Sep 17, 2011, at 14:42, Usman Latif osmankh@yahoo.com wrote:
Ditto Mark -
And I tend to disagree that if IPv6 did not have autoconfiguration feature, then IPv6 would have been devised with only 64 bits ?? It does not make sense coz then you are only increasing 32 bits more to the current size of the IP which IMO would not have been a significant increase in the IP size. IMO IPv6 was
It would have been a 4.2Billion x increase. You don't think that's significant? You and I have very different ideas of what constitutes a significant increase in size.
If you go back and review the records of the IETF from the time, you will find that the discussion centered largely around a 64 bit address space until the idea of stateless auto configuration was proposed and that it did, indeed, spur the idea to add another 64 bits to cover it.
devised with 128 bits and was meant to address infinitely large number of hosts so that we never run out of addresses - and autoconfiguration etc were features added to IPv6 protocol later to make addressing easy. I see autoconfiguration as a feature only and nothing more than that.
The history in the IETF mailing lists differs from your statement here.
RFC 4291 does not pose any restriction or requirement on the IPv6 address assignment architecture that every subnet should or must be /64 or /48 etc and why it cannot be a /112 or something smaller.
Correct. You can do whatever you want with your network. There are other places where /64, /48, and /32 are recommended and, IMHO, /64 per subnet, /48 per end site and minimum /32 per ISP are good starting points and current best common practice.
You are welcome to do otherwise, just as you are welcome to put sugar into your gas tank. However, being stingy with IPv6 resources will degrade the overall capability of your network(s) and possibly the internet, just as putting sugar in your gas tank will degrade the performance of your car.
Owen
From: Mark Tinka mtinka@globaltransit.net To: Owen DeLong owen@delong.com Cc: Skeeve Stevens Skeeve@eintellego.net; sig-policy@lists.apnic.net Sent: Sunday, 18 September 2011 4:02 AM Subject: Re: [sig-policy] Need to understand logic behind assigning /64 IPv6 addresses
On Sunday, September 18, 2011 01:43:13 AM Owen DeLong wrote:
Multiple prefix sizes, address fragmentation, etc. Admittedly, it's a small complication, but, it is a complication.
Further, it violates the principle of least surprise as your organization scales and brings in new engineers.
A good v6 address assignment policy for one's infrastructure is neither difficult to create nor maintain.
No issues here since we started running v6 over 6 years ago. We know how v6 can make address management within an ISP's network brain-dead to maintain, but it's not reason enough to use /64's where we can comfortably use /112's and still not overly complicate our lives.
So did I. I was being a little tongue in cheek/snarky with just presenting the math on the number of addresses,...
I know what you were getting at, with multiple v6 addresses on a single interface, e.t.c.
but the reality is that there may be some cases where having multiple addresses for one end of a point to point or the other (or both) may prove useful. These are admittedly rare.
Agree, but having run multiple networks with v6 over the last several years, we're yet to find with a reason that has required us to have multiple addresses on point-to-point links either between infrastructure, or between AS domains. Some things really are that simple :-).
Obviously, I can't speak for anyone else's network, just ours.
Mark.
sig-policy: APNIC SIG on resource management policy *
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Hi,
On 18 September 2011 13:24, Usman Latif osmankh@yahoo.com wrote:
I sense the recommendations for /64 assignments even to residential users looks more political than technical.
It seems that because end-hosts and other systems have already been built with more support for stateless autoconfig, this may act as a roadblock for us.
First of all, the RFC-6177 does not give the reasoning behind suggesting /64 as being technically motivated but more from the perspective of growth and scalability - I for one am having a hard time imagining how a "residential site" can grow to such a length that it would need 2^64 address space. ...
For comparison, look at Netware IPX from the '80s and '90s. http://en.wikipedia.org/wiki/Internetwork_Packet_Exchange --- * Logical networks are assigned a unique 32-bit hexadecimal address in the range of 0x1 - 0xFFFFFFFE. * Hosts have a 48-bit node address which by default is set to the network interface card's MAC address. The node address is appended to the network address to create a unique identifier for the host on the network. --- 32 + 48 = 80 bits c.f. IPv6's 128 bits.
Building an IPX network was simple because hosts auto-configured themselves. No host counting or pre-registration required. Joining 2 enterprise networks together was problematic because both sides would have used network "1", "2" ... or "A" "B" ...
If you were to add 48 bits of Site IPv6 address to IPX you get 48 + 32 + 48 = 128 bits of address. The split between subnet and host numbers is different from normal IPv6 48 + 16 + 64 ... but network interface identifiers could grow from 48 to 64 bits (e.g. one-wire device ID)
I think that this shows that 64 bits is not overly excessive for host address number.
John
On 18/09/2011, at 9:42 AM, Usman Latif wrote:
And I tend to disagree that if IPv6 did not have autoconfiguration feature, then IPv6 would have been devised with only 64 bits ?? It does not make sense coz then you are only increasing 32 bits more to the current size of the IP which IMO would not have been a significant increase in the IP size. IMO IPv6 was devised with 128 bits and was meant to address infinitely large number of hosts so that we never run out of addresses - and autoconfiguration etc were features added to IPv6 protocol later to make addressing easy. I see autoconfiguration as a feature only and nothing more than that. RFC 4291 does not pose any restriction or requirement on the IPv6 address assignment architecture that every subnet should or must be /64 or /48 etc and why it cannot be a /112 or something smaller.
Let me put this another way...
If IPv6 had been designed with 512 bits and then someone had suggested adding 64 for autoconf and it was increased to 576, would you be arguing for a greater allocation than 512 bits per host? I'll assume your answer is 'of course not because 512 bits is so big', in which case it should hopefully be clear that the discussion should not be about how the last 64 bits are used, but whether the bits proceeding those last 64 are enough and how they are used.
It seems clear from Owen's maths that the first 64 bits is plenty provided that if our current policy turns out to be excessive then we correct it later with a better policy.
Personally I'm pretty convinced that assigning /48 instead of /56 to a CPE and /32 to any LIR is excessive and the large allocations of /13 to the US DoD and /19 to EU telcos are astonishingly questionable and so the policy will inevitably have to change, but I have to acknowledge that it is not so urgent that we can't wait a while to see what happens. Maybe 'the Internet of things' will take off and my house will be full of devices demanding addresses and a /48 will seem a sensible choice. I'm not holding my breath though.
cheers Jay
Activity Summary
- 4019 days inactive
- 4019 days old
- sig-policy@lists.apnic.net
- 8 participants
- 17 comments