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
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
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
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
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 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.