IPv6 fc00::/7 — Unique local addresses

Mailman List Mirror (Read Only)
101

(Response inline).

We've decided to disable SLAAC (State-Less Address Auto-Configuration)
on almost all our IPv6 networks and use DHCPv6 exclusively. This

Ouch... Sounds painful.

Really? I don't know. Maybe as a consultant you don't see it, but I
can't run a non-trivial network without having control over which
hosts get an IPv6 address (and knowing which address they get) without
creating a lot more work running around putting out fires. From a
"buy-in" standpoint, SLAAC was a non-starter, giving people an option
where they could enable IPv6 on a host-by-host basis ended up being
the quickest path to adoption without IPv6 getting a black eye because
of a security issue that couldn't be quickly dealt with, or older
systems (RHEL 3 comes to mind) having an IPv6 bug triggered and
crashing.

IPAM is a critical component of IPv6 for any non-trivial deployment
IMHO, I know Apple disagrees, but OK.

allows us to only respond with DHCPv6 to the hosts we want to get an
IPv6 address instead of enabling it network-wide and crossing your
fingers. The disadvantage here is that DHCPv6 client support is still
limited (OS X has none for example). The argument is that IPv6 isn't
mission critical yet, so we're waiting to see if vendors will come
around and include DHCPv6 client support in the future.

It also means that you are even more subject to the issues of rogue
RA and RA Spoofing.

How so? We still have RA (with a high priority) that's the only way
DHCPv6 works. I guess there is a lot of misunderstanding about how
DHCPv6 works, even among the experts...

Another thing you want to do is block rogue RA. RA-Guard is the
feature name, but nobody has a working implementation yet. If you
have switches that can do port-based access-lists with IPv6 you can
create ingress filters to block out incoming RA on a per-port basis
which is what we have done.

You must have a really hostile user base. I agree RA-Guard is a good
idea and it does work on some switches. Where it is most glaringly
lacking is in Wireless configurations, meaning that having a real RA
is actually a limited measure of protection vs. having no RA.

Again, it sounds like you think DHCPv6 means no RA? This is not the
case. I consider filtering RA (accidental or malicious) critical for
any network, regardless of whether IPv6 is deployed or not.

Just above you were complaining about me having problems with rogue
RA... Now you're saying I'm being paranoid? I know you work for HE
and everything, but really?

If you don't block RA, you can get mis-configured hosts (Windows ICS
comes to mind) hijacking traffic without even knowing about it on
networks that you don't have IPv6 deployed on. That's the accidental
side, though.

On the malicious side, I consider IPv6 one of todays most effective
attack vectors. I can easily jump on a network that doesn't even
monitor IPv6, declare myself as a router, advertise myself as IPv6
DNS, and proxy all traffic on a network, often without setting off
alarms. Remember, hosts by default usually have IPv6 enabled, and
usually prefer IPv6 over IP. In the case of servers, most
administrators who are diligent about making sure host-based firewalls
are in place completely forget about IPv6, because they haven't
deployed it yet.

Just because you haven't deployed IPv6 doesn't mean it's not running
on your network.

This is especially true in an academic setting where people bring
their own computers on to your network.

Not filtering rogue RA seems a little insane, IMHO. I'm still shocked
that RA-Guard hasn't become the default in modern switching... but if
you don't think it's a problem, that works too.

What are the odds that there will be a virus, worm, or tojan that
decides to turn infected hosts into IPv6 routers, anyway...

I really don't buy the argument that "advertising IPv6 yourself with a
high priority will mitigate the impact of rogue RA". As mentioned,
DHCPv6 still requires RA to work... by design, so your point is moot.
But regardless, that mindset only protects against accidental rogue
RA, not malicious RA, which is a significant security threat and
_should_ be filtered as a best practice when possible.

I would go as far as to argue it's worth pushing up switch upgrades to
make sure you have hardware capable of doing so, but maybe I am just
being paranoid.

102

I keep hearing this and it never makes sense to me.

If your provider will assign you a static /48, then, you have stable
addresses when your provider link is down in GUA. Who needs ULA?

You used the word "if". Reverse the sense of the "if" and see if
it still doesn't makes sense to use ULA addresses. I get a mostly
stable IPv4 address from my cable provider (DHCP). That address
changes without notice about once a year. I can configure a 6to4
prefix based on that address (effectively a PA prefix). I use ULA
addresses internally and 6to4 (PA) externally. Same for 6rd. Same
for PD.

I use the dynamic address from my cable provider to terminate a set
of GRE tunnels to my colo routers.

I use the static address from my DSL provider to terminate other
GRE tunnels to my colo routers.

The DSL tunnels are all carrying both IPv4 and IPv6.

When the cable address changes, the BGP sessions over those
GRE tunnels drop and my network connection slows down.
When I repair the tunnels with the new end-point address,
everything goes back to fast.

DHCP derived 6to4, DHCP derived 6rd, DHCP derived Terado and PD all
give you leased prefixes. They are not guarenteed to be STABLE.
For internal communication you really do want stable prefixes. ULA
gives you those stable prefixes.

Yep... Makes much more sense to have at least one provider with static
and do native IPv6 than to use 6to4, 6rd, Teredo, or PD.

You talk to the world using PA addresses, directly for IPv6 and
indirectly via PNAT for IPv4. These can change over time.
=20

Or, if you don't want your IPv6 addresses to change over time, you can
get a prefix from your friendly RIR.

You really think I'm going to go to my RIR and get a addresses block
for my home network then my cable provider will route it for me?

No... I think you might go to your RIR and get an address block
for your home network then find a way to use your cable provider
for L2 transport and route it. That solution works quite well for me.

Similarly, ULA + 6to4 works well provided the 6to4 works when you
are connected. When your IPv4 connection is renumbered you have a
new external addresses but the internal addresses stay the same.
=20

That's a big "provided that"...

Not really. It works for lots of people.

Then how come I hear a lot more 6to4 horror stories than 6to4
success stories? It's not like I don't talk to lots of people using
these protocols on a daily basis.

And you expect the routing system to cope when 2 billion homes do the
same thing?

As a matter of fact, I think the routing system damn well better start planning
to cope with just that scenario. I think it is inevitable in one form or another.

Owen

103

Ray said: ".. But then why wouldn't you just ask for a GUA at that point."

What's the cost for a /48 GUA from ARIN these days? Why pay for
something that you're not going to "use"?

$1250 initial and $100/year thereafter. If you have any other end-user
resources, it's part of the same $100/year you're already paying, so,
it might be effectively free after the initial payment.

Assuming you use it for 10 years, that amortizes out to $125/year.

I don't know if there are still discounts on end-user assignments or
not. I know that when I got mine, there was a partial fee waiver
program in effect and I paid quite a bit less than $1250.

I agree with you but as long as the RIRs charge for integers people
will make up their own if they can find a way.

The RIRs don't charge for integers. The RIRs charge for making
globally guaranteed unique registrations of integers and
maintaining the associated records in several databases.

If a small shop guy is looking at ether paying for GUA space or
affording a more expensive switch that will do SNMP, he's going to get
the switch.

There are places to get legitimate GUA space other than RIRs.

Some of them are free.

Owen (KB6MER, btw)

104

If your big enough to get your own GUA and have the dollars to get
it routed then do that. If you are forced to use PA (think home
networks) then having a ULA prefix as well is a good thing.

home network: 2620:0:930::/48

In Oz it costs real money to get IPv6 address space from the RIR
(APNIC). Around AUD$6K in the first year, around AUD$1100 each year
thereafter.

Your /48, according to the ARIN website, cost you US$625 this year, will
cost US$937.50 next year, and $1250 every year thereafter.

Uh, no... You're misreading it.

It cost me $625 (or possibly less) one-time when I first got it.

After that, the annual $100/year has been part of the same $100/year
I've been paying for my IPv4 resources.

Fairly trivial amounts for most commercial entities, but prohibitive for
all but the most enthusiastic home user.

Agreed, but, at $100/year that I was already paying for IPv4, it seemed
pretty trivial. I bet you spend more than that at Starbucks each year.

Owen

105

Where does the 6K come from?

AUD$4,175 is the amount - It consists of the "Associate Member
Fee" (AUD 675) and the IP Resource Application Fee (AUD 3,500)

Then AUD1180 for a /48 each year.

Er - apologies. Yes, the initial fee covers the first year's annual fee,
so it's $4175 in the first year ans $1100 in subsequent years.

The point still stands though - that's WAY too much for home users.

While for Owen such costs might be doable, for the vast majority of home
users in the AP region the only viable alternatives for internal
addressing will be PA or ULA.

This is NANOG. To the best of my knowledge, no part of the NA in NANOG
is in the APNIC service area.

ARIN pricing is significantly better at US$100/year for ALL end-user
resources, so, only the $1250 up-front fee would apply and apparently
the partial fee-waiver for that is still in effect if your previous posting
was correct.

Even with the lower costs that ARIN users pay, the prices are still IMHO
too high for home users to be using PI in any significant numbers.

Really? $100/year is too much? Really? I guess that depends on whether
you think addresses are worth more than coffee. :wink:

Owen

106

Given the number of times and the distance over which I have seen RFC-1918
routes propagate, this belief is false to begin with, so, removing this false sense
of security is not necessarily a bad thing.

I don't think it's really a propagation issue. As the ISP, I don't actually route RFC-1918 space to my corporate customers, many of which maintain static assignments (no routing protocol). While they can leak packets out, there will never be a return of packets to them. They view this as a feature.The tragedy won't be networks deploying NAT. I'm all for allowing you to buy

a gun, ammunition, and aim at your foot or head as you wish.

The tragedy will be if enough networks do this to hobble development of truly
useful tools that depend on a NAT-free environment to work.

I think we should respect the different types of networks, and their administrative goals. I have customers who manage large educational networks. Their engineers have a strong belief in free speech and openness. They have very few filters, don't utilize NAT, and have a reactionary security policy. I also have corporate customers who run extreme nat, don't allow access to social network sites, proxy every communication in and out, and generally don't care that they break 90%+ of the applications that work over the Internet, especially when it's not business related.

That being said, I've seen corporate networks change, altering their security policy and the way they do things in order to support applications which they desire. So I wouldn't be surprised if a tight NAT dwelling network suddenly shifted to routing global addressing to meet new applications needs.

Jack

107

Actually, the last I checked, there are implementation of DHCPv6 without RA.

Jack

108

How do you do that for IPv4... There's nothing new here. The failure
modes
are identical and your NAT box in IPv4 doesn't protect you from this
any
better.

With IPv4 I don't generally use two sets of prefixes for the same
traffic from the same site to the Internet unless there is some sort of
appliance in the path that somehow decides the "best" one to use for NAT
and even then I am not convinced of such a device's utility in a general
purpose sense. There might be corner cases where such an option is
useful, though. I was making the point that trying to use two prefixes
for the same traffic from the same site as some sort of redundancy
doesn't really offer it because it only offers relief if your link to
the provider drops. There are all sorts of other problems that can
happen out on "the net" to make one prefix reachable but the other one
not reachable from a remote site. Multihoming the same prefix from two
providers is generally more reliable because if the remote network can
"see" either provider, you are good and traffic can "fail over" from
provider A to provider B in the course of a transaction without
disruption.

To recap, this tangent of the original thread was about the typical
practice at small offices without a lot of network savvy to number the
network in 1918 space and use a NAT at the Internet edge. To change
providers, you simply change the NAT pool and you are done.

With v6, while changing prefixes is easy for some gear, other gear is
not so easy. If you number your entire network in Provider A's space,
you might have more trouble renumbering into Provider B's space because
now you have to change your DHCP ranges, probably visit printers, fax
machines, wireless gateways, etc. and renumber those, etc. And some
production boxes that you might have in the office data center are
probably best left at a static IP address, particularly if they are
fronted by a load balancer where their IP is manually configured.

The complaint was that there is no equivalent in v6 and that someone is
probably going to build and sell one and we will be right back in the
same situation with v6 with networks in ULA space being NATed at the
edge. People aren't going to want very much of their network
infrastructure support tied to a provider's IP space.

The small operation of which there are millions in this country, cannot
justify the expense of multihoming for the sole reason of having an IP
address range that doesn't change. As soon as the same configuration
currently used is available for v6, you will see mass adoption of it.
The lack of this currently in the market is probably one of the major
drags on the adoption of v6 in the small office environment. People
just do not want to number their internal network into PA space and
can't justify the requirements to get PI space.

109

Well have the hosts update their own addresses in the DNS. That's
one of the problems addressed. There are at least two commercial
OSs which will do this for you.

Mark

But they sometimes don't check to make sure there aren't stale DNS entries for their hostname before they add the new one! I have run into that problem often. A machine that has been "bounced" several times recently might have a dozen A records for its hostname in DNS. I won't mention any names but their initials are MICROSOFT. For many of our machines, there are load balancers, even in the office data center with hard coded IP addresses for the backend servers. Dynamic address assignment isn't really an option but works fine for things like user machines in the cubes. You aren't going to be looking those up by A record anyway. Static assignment by DHCP is possible for the devices that do that, you just have to remember to change it if you change a NIC (or if the interfaces are bound together on the box, such as with linux bonding, the "master" interface of the bond changes for some reason like a failure of the previous master). Static hard coding of the IP address is actually easier to manage in the colo than DHCP or autoconfiguration.

110

Many of these problems are application/implementation issues. Many devices need support for dynamic prefix specifications "hey, my destination for the load balancer is $prefix:blah", and some devices still need support for just setting their IP with RA (though all my servers do it fine).

At this time, there are many situations where static assignment is probably the only option. Multiple assignments may not be out of the question. However, this is due to the shortage of what IPv6 *could* be. We are missing so many support protocols and applications that could truly make it far superior to IPv4. Then again, I think SCTP is superior to udp/tcp, and I don't think I have a single app using it.

Jack

111

In a message written on Thu, Oct 21, 2010 at 07:21:41PM -0700, George Bonser wrote:

With v6, while changing prefixes is easy for some gear, other gear is
not so easy. If you number your entire network in Provider A's space,
you might have more trouble renumbering into Provider B's space because
now you have to change your DHCP ranges, probably visit printers, fax
machines, wireless gateways, etc. and renumber those, etc. And some
production boxes that you might have in the office data center are
probably best left at a static IP address, particularly if they are
fronted by a load balancer where their IP is manually configured.

The complaint was that there is no equivalent in v6 and that someone is
probably going to build and sell one and we will be right back in the
same situation with v6 with networks in ULA space being NATed at the
edge. People aren't going to want very much of their network
infrastructure support tied to a provider's IP space.

It would seem to me there is a market for a "new sort of NAT" with
IPv6. That is the technology is not new, but it's a model we can't
do in IPv4.

If you could number your internal network out of some IPv6 space
(possibly 1918 style, possibly not), probably a /48, and then get
from your two (or more) upstreams /48's of PA space you could do
1:1 NAT. No PAT, just pure address translation, 1:1.

You can "renumber" by configuring a new outside translation. The
NAT box can do the load distribution functions discussed here, some
users out one provider, others out the second provider. There is
no port complication, so incoming connections are much simpler.

It's a vast improvement over the port based mess we have now, and
provides an interesting way to "multihome" at the edge. If we could get
a simple protocol, in the model of UDLD to go NAT box to Provider router
to establish that it was up, and a little bit of DNS software magic to
make it easier to manage the external addresses appearing in DNS for
exposed services this could solve the vast majority of small site
multihoming needs.

What makes it all possible is the same prefix length internally and
from all providers. It's a reason why /48 could be important.

Given all effort put into "better" multihoming in IPv6 I'm really
surprised this simple solution which basically exists in code today
(porting an IPv4 NAT to IPv6, if there is no PAT, is easy).

112

In message <3D230C80-E7CC-4B73-9E47-780DF5FA33AC@delong.com>, Owen DeLong write
s:

>> Where does the 6K come from?
>>
>> AUD$4,175 is the amount - It consists of the "Associate Member
>> Fee" (AUD 675) and the IP Resource Application Fee (AUD 3,500)
>>
>> Then AUD1180 for a /48 each year.
>
> Er - apologies. Yes, the initial fee covers the first year's annual fee,
> so it's $4175 in the first year ans $1100 in subsequent years.
>
> The point still stands though - that's WAY too much for home users.
>
> While for Owen such costs might be doable, for the vast majority of home
> users in the AP region the only viable alternatives for internal
> addressing will be PA or ULA.
>
This is NANOG. To the best of my knowledge, no part of the NA in NANOG
is in the APNIC service area.

ARIN pricing is significantly better at US$100/year for ALL end-user
resources, so, only the $1250 up-front fee would apply and apparently
the partial fee-waiver for that is still in effect if your previous posting
was correct.

Which is still too expensive for the home user.

> Even with the lower costs that ARIN users pay, the prices are still IMHO
> too high for home users to be using PI in any significant numbers.
>
Really? $100/year is too much? Really? I guess that depends on whether
you think addresses are worth more than coffee. :wink:

$100/year for a address block that nobody will route and requires someone
to setup the address selection rules compared to a ULA at $0 that the OS
vendors will make work well by default.

113

From: Leo Bicknell
Sent: Thursday, October 21, 2010 7:53 PM
To: NANOG list
Subject: Re: Failover IPv6 with multiple PA prefixes (Was: IPv6
fc00::/7 -Unique local addresses)

What makes it all possible is the same prefix length internally and
from all providers. It's a reason why /48 could be important.

Right. /48 is the secret sauce in that. What you could do is:

Assume a new connection to a destination you have not spoken to yet.
SYN arrives from the inside machine trying to connect out. NAT box sends
a SYN from each of the NATed IPs for the upstream providers. The one
that returns first "wins" and that is the prefix you use to NAT that
connection, the other one gets RST. You remember which upstream is
associated with that connection for some period of time and reuse it.
After some period of time elapses you would "forget" and test again on a
new connection attempt. That at least gives you assurance the remote
site has a path back to that IP and you are going with the higher
performing path. You might even have an option to "nail" certain inside
IPs to a certain path or certain remote destinations to a certain path.

Given all effort put into "better" multihoming in IPv6 I'm really
surprised this simple solution which basically exists in code today
(porting an IPv4 NAT to IPv6, if there is no PAT, is easy).

It would seem that simply translating the source /48 would be simple
enough but would probably break something. Might break some Microsoft
secure connection protocols where the IP in the header doesn't match the
reported IP inside the packet, though, but that could probably be fixed,
too.

114

In message <4BC01459-B53A-4B2C-B75B-47D89550DFC5@delong.com>, Owen DeLong write
s:

>=20
> In message <E22A56B3-68F1-4A75-A091-E416800C485B@delong.com>, Owen =
DeLong write
> s:
>>>>>=20
>>>> Which is part one of the three things that have to happen to make =
ULA
>>>> really bad for the internet.
>>>>=20
>>>> Part 2 will be when the first provider accepts a large sum of money =
to
>>>> route it within their public network between multiple sites owned =
by
>>>> the same customer.
>>>>=20
>>>=20
>>> That same customer is also going to have enough global address
>>> space to be able to reach other global destinations, at least enough
>>> space for all nodes that are permitted to access the Internet, if =
not
>>> more. Proper global address space ensures that if a global =
destination
>>> is reachable, then there is a high probability of successfully =
reaching
>>> it. The scope of external ULA reachability, regardless of how much
>>> money is thrown at the problem, isn't going to be as good as proper
>>> global addresses.
>>>=20
>> _IF_ they implement as intended and as documented. As you've
>> noted there's a lot of confusion and a lot of people not reading the
>> documents, latching onto ULA and deciding ti's good.
>>=20
>> It's not a big leap for some company to do a huge ULA deployment
>> saying "this will never connect to the intarweb thingy" and 5-10 =
years
>> later not want to redeploy all their addressing, so, they start =
throwing
>> money at getting providers to do what they shouldn't instead of
>> readdressing their networks.
>=20
> IPv4 think.
>=20
> You don't re-address you add a new address to every node. IPv6 is
> designed for multiple addresses.
>=20
That's a form of re-addressing. It's not removing the old addresses, =
but,
it is a major undertaking just the same in a large deployment.

I don't see any major difference in the amount of work required to
go from disconnected ULA to ULA + PA/PI or ULA + NAT compared to
disconnected PI to connected PI. Whether the machines have one or
two address is inconsequential in the grand scheme of things.

>>> For private site interconnect, I'd think it more likely that the
>>> provider would isolate the customers traffic and ULA address space =
via
>>> something like a VPN service e.g. MPLS, IPsec.
>>>=20
>> One would hope, but, I bet laziness and misunderstanding trumps
>> reason and adherence to RFCs over the long term. Since ULA
>> won't get hard-coded into routers as unroutable (it can't),
>=20
> Actually it can be. You just need a easy switch to turn it off. The
> router can even work itself out many times. Configure multiple =
interfaces
> from the same ULA /48 and you pass traffic for the /48 between those
> interfaces. You also pass routes for that /48 via those interfaces.
>=20
If you have an easy switch to turn it off, it will get used, thus =
meaning that
it isn't hard coded, it's just default.

On by default will create a effective deterrent.

115

You assume the protocol(s) don't include IP addresses inside the
payload.

You also assume the protocol(s) don't do things like checksum
application payloads, which include IP addresses.

Both of which I've seen, today. Some of which I occasionally see
inside, hm, "over-enthusiastic" HTTP procotol/application
designers.

NAT's going to be needed, but it's going to be more stateful
inspection-y than most of the vocal nanog+ipv6 people desire. :slight_smile:

Adrian

116

Uh, no... You're misreading it.

Yes - I read the ISP bit, not the end user bit.

It cost me $625 (or possibly less) one-time when I first got it.

That was with the waivers in force. It will soon cost a one-time US
$1250. We could argue till the cows come home about what proportion of
the population would consider that "prohibitive" but I'm guessing that
even in the USA that's a heck of an entry fee, and that the vast
majority of non-corporate end users will not be willing to pay it. Which
is the actual point, rather than quibbling about the precise price.

I bet you spend more than [US$100] at Starbucks each year.

You lose! The nearest Starbucks to me[1] is approximately 700km
distant :slight_smile:

Please transfer AUS$4175 immediately, bank details under separate
cover :slight_smile:

Regards, K.

[1] According to the online Starbucks store locator...

117

In message <B8AA2A26-3B41-4427-90F6-26EB9E6BE227@delong.com>, Owen DeLong write
s:

>>>
>> I keep hearing this and it never makes sense to me.
>>
>> If your provider will assign you a static /48, then, you have stable
>> addresses when your provider link is down in GUA. Who needs ULA?
>
> You used the word "if". Reverse the sense of the "if" and see if
> it still doesn't makes sense to use ULA addresses. I get a mostly
> stable IPv4 address from my cable provider (DHCP). That address
> changes without notice about once a year. I can configure a 6to4
> prefix based on that address (effectively a PA prefix). I use ULA
> addresses internally and 6to4 (PA) externally. Same for 6rd. Same
> for PD.
>
I use the dynamic address from my cable provider to terminate a set
of GRE tunnels to my colo routers.

<

I use the static address from my DSL provider to terminate other
GRE tunnels to my colo routers.

The DSL tunnels are all carrying both IPv4 and IPv6.

When the cable address changes, the BGP sessions over those
GRE tunnels drop and my network connection slows down.
When I repair the tunnels with the new end-point address,
everything goes back to fast.

You've gone way past what the average home user can or should be
expected to handle here. Your well into advanced user territory.

I've done the same sort of thing but I don't see myself as a average
home user.

The average home user should be able to plug in a home router into
the network connection from the ISP. Plug that into a 10/100/1000
switch or turn on WiFi and plug in there hosts / enable WiFi on the
hosts and have the network work regardless of whether the upstream
is working or not.

If they have bought the multi-upstream router then plug all isps
in (Cable/DSL/WiMax/....) and have the whole thing work regardless
of how many upstream links are working.

> DHCP derived 6to4, DHCP derived 6rd, DHCP derived Terado and PD all
> give you leased prefixes. They are not guarenteed to be STABLE.
> For internal communication you really do want stable prefixes. ULA
> gives you those stable prefixes.

Yep... Makes much more sense to have at least one provider with static
and do native IPv6 than to use 6to4, 6rd, Teredo, or PD.

Well when you can get agreements from all the residential ISPs to
provide static IPv6 address come back to me. In the meantime I'm
going to plan how to handle non static assignments,

>>> You talk to the world using PA addresses, directly for IPv6 and
>>> indirectly via PNAT for IPv4. These can change over time.
>>> =3D20
>> Or, if you don't want your IPv6 addresses to change over time, you =
can
>> get a prefix from your friendly RIR.
>
> You really think I'm going to go to my RIR and get a addresses block
> for my home network then my cable provider will route it for me?
>
No... I think you might go to your RIR and get an address block
for your home network then find a way to use your cable provider
for L2 transport and route it. That solution works quite well for me.

You still had to have someone route it somewhere be it the cable
provider or someone else you reach over the cable provider.

>>> Similarly, ULA + 6to4 works well provided the 6to4 works when you
>>> are connected. When your IPv4 connection is renumbered you have a
>>> new external addresses but the internal addresses stay the same.
>>>
>> That's a big "provided that"...
>
> Not really. It works for lots of people.
>
Then how come I hear a lot more 6to4 horror stories than 6to4
success stories? It's not like I don't talk to lots of people using
these protocols on a daily basis.

Because people complain when things break. They are silent when things
work.

118

I'll go out on a limb here and say that RA is not needed for DHCPv6.

A DHCPv6 client multicasts all its messages to the well-known
all-relays-and-servers address. A client needs only its link-local
address to do this. The relay (or server if it happens to be on the same
link) can thus talk to the client in the complete absence of RA.

Regards, K.

119

Announce your gua and then blackhole it and monitor your prefix.
you can tell if you're leaking. it's generally pretty hard to
tell if you're leaking rfc 1918 since your advertisement may well
work depending on the filters of your peers but not very far.

This is always the argument I hear from corporate customers
concerning wanting NAT. If mistake is made, the RFC 1918 space
isn't routable. They often desire the same out of v6 for that
reason alone.

the rfc 1918 space is being routed inside almost all your adjacent
networks, so if their ingress filtering is working as expected, great,
but you're only a filter away from leaking.

Given the number of times and the distance over which I have seen
RFC-1918 routes propagate, this belief is false to begin with, so,
removing this false sense of security is not necessarily a bad
thing.

this happened this morning in a pop we have in the far east... packets
ended up in atlanta. what's more, the return path was natted.

120

Perfect. Let's not pollute DFZ more than needed.