I've just set up a vpn tunnel to Amazon's AWS and as part of the config they required me to configure to /30 tunnels using addressing from the 169.254.0.0/16 space. RFC3927 basically says that this address should only be used as a temp measure until the interface has a proper private or public address. So what's the consensus then? Is their a problem using this space as link-local address for routers here and there (I mean we have 65K addresses wasted in this block) or is it a strict no-no? And if no, why is Amazon using it? Thanks Darren
On Wed, Oct 17, 2012 at 06:59:09PM +0100, Darren O'Connor wrote:
I've just set up a vpn tunnel to Amazon's AWS and as part of the config they required me to configure to /30 tunnels using addressing from the 169.254.0.0/16 space.
Yeah, they do that for Direct Connect.
RFC3927 basically says that this address should only be used as a temp measure until the interface has a proper private or public address.
So? :)
So what's the consensus then? Is their a problem using this space as link-local address for routers here and there (I mean we have 65K addresses wasted in this block) or is it a strict no-no? And if no, why is Amazon using it?
RFCs are just paper. As for why they use it.. the common private use reserved blocks (10/8, 172.16/12, 192.168/16) are all in use internally in their customers networks. This is probably the easiest way to avoid addressing conflicts. Since these networks are all isolated, I don't see a great deal of harm in it (probably less than overlapping more commonly used private blocks.) --msa
I would agree. I don't see it as a problem using it, but I was mainly wondering about what other people thought of using it. And yes, it's nice to use as people are using RFC1918 addresses in their networks and you can be sure that 169.254.0.0/16 isn't used. At least until people do start using it and then you have the same overlapping problem again
Date: Thu, 18 Oct 2012 11:18:56 -0400 From: msa@latt.net To: darrenoc@outlook.com CC: nanog@nanog.org Subject: Re: 169.254.0.0/16
On Wed, Oct 17, 2012 at 06:59:09PM +0100, Darren O'Connor wrote:
I've just set up a vpn tunnel to Amazon's AWS and as part of the config they required me to configure to /30 tunnels using addressing from the 169.254.0.0/16 space.
Yeah, they do that for Direct Connect.
RFC3927 basically says that this address should only be used as a temp measure until the interface has a proper private or public address.
So? :)
So what's the consensus then? Is their a problem using this space as link-local address for routers here and there (I mean we have 65K addresses wasted in this block) or is it a strict no-no? And if no, why is Amazon using it?
RFCs are just paper. As for why they use it.. the common private use reserved blocks (10/8, 172.16/12, 192.168/16) are all in use internally in their customers networks. This is probably the easiest way to avoid addressing conflicts.
Since these networks are all isolated, I don't see a great deal of harm in it (probably less than overlapping more commonly used private blocks.)
--msa
On Thu, Oct 18, 2012 at 11:18 AM, Majdi S. Abbas <msa@latt.net> wrote:
RFCs are just paper. As for why they use it.. the common private use reserved blocks (10/8, 172.16/12, 192.168/16) are all in use internally in their customers networks. This is probably the easiest way to avoid addressing conflicts.
but, but, but!! we have that nifty new '1918' space... 100.64.0.0/10 :)
Wait! Are you suggesting to not use it as intended by RFC6598? "to be used as Shared Address Space to accommodate the needs of Carrier- Grade NAT (CGN) devices. It is anticipated that Service Providers will use this Shared Address Space to number the interfaces that connect CGN devices to Customer Premises Equipment (CPE)" :) .as On 18/10/2012 13:25, Christopher Morrow wrote:
On Thu, Oct 18, 2012 at 11:18 AM, Majdi S. Abbas <msa@latt.net> wrote:
RFCs are just paper. As for why they use it.. the common private use reserved blocks (10/8, 172.16/12, 192.168/16) are all in use internally in their customers networks. This is probably the easiest way to avoid addressing conflicts.
but, but, but!! we have that nifty new '1918' space... 100.64.0.0/10
:)
On 10/19/12 10:56 AM, Arturo Servin wrote:
Wait!
Are you suggesting to not use it as intended by RFC6598?
"to be used as Shared Address Space to accommodate the needs of Carrier- Grade NAT (CGN) devices. It is anticipated that Service Providers will use this Shared Address Space to number the interfaces that connect CGN devices to Customer Premises Equipment (CPE)"
:) It's a private scope address range what you actually do with it only Germain within your span of control. unless you 're sufficiently unwise as to be accepting leaked routes from you upstream in which case it isn't.
http://bgp.he.net/net/100.100.0.0/24#_bogon
.as
On 18/10/2012 13:25, Christopher Morrow wrote:
On Thu, Oct 18, 2012 at 11:18 AM, Majdi S. Abbas <msa@latt.net> wrote:
RFCs are just paper. As for why they use it.. the common private use reserved blocks (10/8, 172.16/12, 192.168/16) are all in use internally in their customers networks. This is probably the easiest way to avoid addressing conflicts.
but, but, but!! we have that nifty new '1918' space... 100.64.0.0/10
:)
I've just set up a vpn tunnel to Amazon's AWS and as part of the config they required me to configure to /30 tunnels using addressing from the 169.254.0.0/16 space.
RFC3927 basically says that this address should only be used as a temp measure until the interface has a proper private or public address.
So what's the consensus then? Is their a problem using this space as link-local address for routers here and there (I mean we have 65K addresses wasted in this block) or is it a strict no-no? And if no, why is Amazon using it? Given the frequency with which adhoc networks are numbered out of this
On 10/17/12 10:59 AM, Darren O'Connor wrote: prefix, it's existence is far from wasted. The term waste is exercised far to liberally in the context of address mangement as far as I'm concerned. If you are unconcerned with possible collisions with ephemeral uses of this space then I imagine you could reuse it for some internal purpose. It is probably important to be aware that unmanaged end systems will use it in an uncoordinated fashion (and make assumptions about the scope of addresses in that range) and that it would therefore be a good idea to limit applications to those which cannot be impacted by that behavior. Amazon does number our VPC peer links out of there. coordinating the existance of multiple private clouds all numbered out of potentially overlapping rfc-1918 address space is probably the motivation for doing so.
Thanks
Darren
participants (5)
-
Arturo Servin -
Christopher Morrow -
Darren O'Connor -
joel jaeggli -
Majdi S. Abbas