Re: Addressing plan exercise for our IPv6 course
Enterprises of non-trivial size will likely use RFC4193 (and I fear we will notice PRNG returning 0 very often) and then NAT it to provider provided public IP addresses.
Eventually ARIN (or someone else will do it for them) may create a site you can register your address and know that it really is unique among participating registrants. Random is fine, unique is better. Such a site would be the seed for when (if) we come up with the tech for everyone to have PI and lose all the restrictions imposed so far.
I'm just hoping that we'll at least see 1:1 NAT instead of NAPT being used.
I think that will be a common PI alternative. If people really don't want NAT then we shouldn't provide reasons for it to exist. RFC4193 seems to be the best enterprise plan. They can link to other enterprises and change ISPs easily or multihome. They are not beholden to any ISP or numbering authority. The global table doesn't explode.
Why on earth would you do that? Why not just put the provider-assigned addresses on the interfaces along side the ULA addresses? Using ULA in that manner is horribly kludgy and utterly unnecessary.
Enterprises tend to want only one identifier to manage per device and that it be unique and mostly permanent. With several PA and ULA on each device, links to ISPs and other enterprises, the combinations of addresses and paths to manage flows and security over become too hard (if it's not simple it's probably not secure). Every device becomes a router and firewall and the staff who manage those aren't cheap.
This is to facilitate easy and cheap way to change provider. Getting PI address is even harder now, as at least RIPE will verify that you are multihomed, while many enterprises don't intent to be, they just need low cost ability to change operator.
Why is that easier/cheaper than changing your RAs to the new provider and letting the old provider addresses time out?
And changing all the ACLs based on the old providers addresses And allowing for all the 5 - 15 year old kit that predates this and won't be upgraded (we have that problem with NT embedded in systems with 10year+ refresh cycle) brandon
On Jul 24, 2010, at 6:40 PM, Brandon Butterworth wrote:
Such a site would be the seed for when (if) we come up with the tech for everyone to have PI and lose all the restrictions imposed so far.
Oh, we have the technology. It's called "memory". Speaking from the perspective of a vendor, I'll happily sell it to you. Don't complain to me about the size of the route table, don't complain to me about heat or power requirements, and don't complain to me about convergence intervals. I'll tell you that you designed the bed you wanted to sleep in, and it was all yours.
Eventually ARIN (or someone else will do it for them) may create a site you can register your address and know that it really is unique among participating registrants. Random is fine, unique is better.
Such a site would be the seed for when (if) we come up with the tech for everyone to have PI and lose all the restrictions imposed so far.
Did you mean something like this maybe ?: http://www.sixxs.net/tools/grh/ula/
On Jul 24, 2010, at 9:40 AM, Brandon Butterworth wrote:
Enterprises of non-trivial size will likely use RFC4193 (and I fear we will notice PRNG returning 0 very often) and then NAT it to provider provided public IP addresses.
Eventually ARIN (or someone else will do it for them) may create a site you can register your address and know that it really is unique among participating registrants. Random is fine, unique is better.
Such a site would be the seed for when (if) we come up with the tech for everyone to have PI and lose all the restrictions imposed so far.
SIXXS already has such a registry with a pretty low adoption rate. I still fail to see any advantage whatsoever to this approach and I think that the limited number of sites that implement it is unlikely to get continued support from ISVs.
I'm just hoping that we'll at least see 1:1 NAT instead of NAPT being used.
I think that will be a common PI alternative. If people really don't want NAT then we shouldn't provide reasons for it to exist.
RFC4193 seems to be the best enterprise plan. They can link to other enterprises and change ISPs easily or multihome. They are not beholden to any ISP or numbering authority. The global table doesn't explode.
I agree that easier to get PI addresses is a better alternative. I will support policy initiatives to do that. RFC4193 remains an utterly horrible idea and NATing it to the public internet remains even worse.
Why on earth would you do that? Why not just put the provider-assigned addresses on the interfaces along side the ULA addresses? Using ULA in that manner is horribly kludgy and utterly unnecessary.
Enterprises tend to want only one identifier to manage per device and that it be unique and mostly permanent.
Right... That identifier is the EUI-64 which is both permanent and unique. The prefix changes when you switch providers, but, that's mostly not particularly horrible since there are tools to make that easier for the bulk of internal hosts.
With several PA and ULA on each device, links to ISPs and other enterprises, the combinations of addresses and paths to manage flows and security over become too hard (if it's not simple it's probably not secure). Every device becomes a router and firewall and the staff who manage those aren't cheap.
Actually, if you set things up correctly, most of the security stuff to manage is about the same because you hairpin the stuff that doesn't need filtration at a point before it hits the packet filters.
This is to facilitate easy and cheap way to change provider. Getting PI address is even harder now, as at least RIPE will verify that you are multihomed, while many enterprises don't intent to be, they just need low cost ability to change operator.
Why is that easier/cheaper than changing your RAs to the new provider and letting the old provider addresses time out?
And changing all the ACLs based on the old providers addresses
Mostly this is a pretty straight forward copy->search->replace problem with prefix changes that can be done with the equivalent of an s/x/y/g construct.
And allowing for all the 5 - 15 year old kit that predates this and won't be upgraded (we have that problem with NT embedded in systems with 10year+ refresh cycle)
That kit won't support IPv6, so, I fail to see the relevance. Any kit that supports IPv6 supports this. Owen
On Sat, 24 Jul 2010 10:57:49 -0700 Owen DeLong <owen@delong.com> wrote:
On Jul 24, 2010, at 9:40 AM, Brandon Butterworth wrote:
Enterprises of non-trivial size will likely use RFC4193 (and I fear we will notice PRNG returning 0 very often) and then NAT it to provider provided public IP addresses.
Eventually ARIN (or someone else will do it for them) may create a site you can register your address and know that it really is unique among participating registrants. Random is fine, unique is better.
Such a site would be the seed for when (if) we come up with the tech for everyone to have PI and lose all the restrictions imposed so far.
SIXXS already has such a registry with a pretty low adoption rate.
And I think that is good news. The fd00::/8 range is not defined as guaranteed globally unique. I'm concerned that the SIXXS registry could imply to those people who have used it, that it is. They may think that because that registry exists, and that they've used it, that address space it now theirs, and nobody else is allowed to use it. Once somebody perceives ownership of something they believe is unique, I think they commonly won't listen to reason about their actual lack of global ownership. fc00::/8 is for guaranteed globally unique ULAs.
I still fail to see any advantage whatsoever to this approach and I think that the limited number of sites that implement it is unlikely to get continued support from ISVs.
I'm just hoping that we'll at least see 1:1 NAT instead of NAPT being used.
I think that will be a common PI alternative. If people really don't want NAT then we shouldn't provide reasons for it to exist.
RFC4193 seems to be the best enterprise plan. They can link to other enterprises and change ISPs easily or multihome. They are not beholden to any ISP or numbering authority. The global table doesn't explode.
I agree that easier to get PI addresses is a better alternative. I will support policy initiatives to do that. RFC4193 remains an utterly horrible idea and NATing it to the public internet remains even worse.
Well I think RFC4193 is a great idea. I don't want my home network addressing to be bound to having a commercial arrangement with an ISP, or having an active Internet connection. I can also use the ULA prefix as a simple designator of trusted verses untrusted traffic sources in firewall rules. I see those advantages equally applicable to enterprise or ISP networks. Then again, I'm happy with the idea of multiple addresses on an interface, and source address selection. They're not much different to those issues in IPv4, such as unnumbered interfaces on routers, designated source addresses for router SNMP traps etc., or source address selection for policy routing.
Why on earth would you do that? Why not just put the provider-assigned addresses on the interfaces along side the ULA addresses? Using ULA in that manner is horribly kludgy and utterly unnecessary.
Enterprises tend to want only one identifier to manage per device and that it be unique and mostly permanent.
That's IPv4 thinking showing though. People fundamentally don't want change when they don't know of or understand the benefits they will gain. ULAs are an overhead, but they also provide benefits that can't be achieved with global address space assigned by an ISP. (I don't accept the PI argument, because it isn't feasible for residential networks).
Right... That identifier is the EUI-64 which is both permanent and unique. The prefix changes when you switch providers, but, that's mostly not particularly horrible since there are tools to make that easier for the bulk of internal hosts.
With several PA and ULA on each device, links to ISPs and other enterprises, the combinations of addresses and paths to manage flows and security over become too hard (if it's not simple it's probably not secure). Every device becomes a router and firewall and the staff who manage those aren't cheap.
Actually, if you set things up correctly, most of the security stuff to manage is about the same because you hairpin the stuff that doesn't need filtration at a point before it hits the packet filters.
This is to facilitate easy and cheap way to change provider. Getting PI address is even harder now, as at least RIPE will verify that you are multihomed, while many enterprises don't intent to be, they just need low cost ability to change operator.
Why is that easier/cheaper than changing your RAs to the new provider and letting the old provider addresses time out?
And changing all the ACLs based on the old providers addresses
Mostly this is a pretty straight forward copy->search->replace problem with prefix changes that can be done with the equivalent of an s/x/y/g construct.
And allowing for all the 5 - 15 year old kit that predates this and won't be upgraded (we have that problem with NT embedded in systems with 10year+ refresh cycle)
That kit won't support IPv6, so, I fail to see the relevance. Any kit that supports IPv6 supports this.
Owen
participants (5)
-
Brandon Butterworth -
Fred Baker -
Leen Besselink -
Mark Smith -
Owen DeLong