Re: IPv6 fc00::/7 - Unique local addresses

[Joel Jaeggli]

On 11/1/10 9:42 PM, Nathan Eisenberg wrote:
>> My guess is that the millions of residential users will be less and
>> less enthused with (pure) PA each time they change service providers...

Hi, almost everytime I open my laptop it gets a different ip address,
sometimes I'm home and it gets that same ip it had the last time I was
there.

once in a very great while my home gateway changes it's ip address,
since it does dynamic dns updates I have no trouble finding it, and in
fact the network storage perhipheral that I have thinks nothing of using
upnp to punch a hole in the gateway all on it's own... These are mostly
low touch and either zero or very little configuration required.

The consumer isn't got to tollerate systems which don't work
automatically or very nearly so, which means among other things having
an ip address change or even have your home gateway(s) help the
downstream devices renumber themselves.

> That claim seems to be unsupported by current experience.   Please elaborate.

It's not only not supported by current experience it seems really
unlikely to be supported by future experience, e.g. many device you have
are mobile, and a connected to more than one network at a time they
still may be gatewaying for downstream devices. if somewhere along the
line you solved this for the mobility case it is going to work for
networks which are more stable.

> Nathan
> 
> 
> 

Re: IPv6 fc00::/7 — Unique local addresses

[David Conrad]

On Nov 2, 2010, at 6:40 AM, Robert E. Seastrom wrote:
> David Conrad  writes:
> 
>> Owen,
>> 
>> On Nov 1, 2010, at 4:59 PM, Owen DeLong wrote:
>>> Yes, one time.
>>> 
>>> Truly one time.
>>> 
>>> No other fees.
>> 
>> Let's say you returned all your IPv4 address space.
>> 
>> What would happen if you then stopped paying?
> 
> He'd lose his ASN.  What do I win?

And not his IPv6 space? ARIN has moved to a "Once and For All" (aka "Cemetery 
Plot") pricing model for IPv6?

Regards,
-drc

Re: IPv6 fc00::/7 — Unique local addresses

[Robert E. Seastrom]

David Conrad  writes:

> Owen,
>
> On Nov 1, 2010, at 4:59 PM, Owen DeLong wrote:
>> Yes, one time.
>> 
>> Truly one time.
>> 
>> No other fees.
>
> Let's say you returned all your IPv4 address space.
>
> What would happen if you then stopped paying?

He'd lose his ASN.  What do I win?

-r

Re: IPv6 fc00::/7 - Unique local addresses

[Mark Smith]

On Tue, 2 Nov 2010 01:24:45 -0400
Ben Jencks  wrote:

> On Tue, Nov 2, 2010 at 00:58, David Conrad  wrote:
> > On Nov 1, 2010, at 6:42 PM, Nathan Eisenberg wrote:
> >>> My guess is that the millions of residential users will be less and
> >>> less enthused with (pure) PA each time they change service providers...
> >> That claim seems to be unsupported by current experience.   Please 
> >> elaborate.
> >
> > Currently, most residential customers have PA+NATv4, where the CPE provides 
> > the public IPv4 address to the NATv4 box (which might be the same box as 
> > the CPE) via DHCP (or PPPoE). As such, all internal devices are shielded 
> > from all renumbering events.  In a NATless PA world, all devices will need 
> > to be renumbered on a change of provider.  While in theory, address 
> > lifetimes and multiple addresses should reduce the impact renumbering might 
> > have, I will admit some skepticism that renumbering IPv6 providers will be 
> > sufficiently transparent as customers are used to with IPv4 PA+NATv4. 
> > Perhaps I am wrong.
> 
> No "average residential user" should ever see or configure an IPv6
> address; all the vendors are using zeroconf etc. to avoid it at all
> costs. If it was all autoconfigured in the first place, there's no
> reason autoconfiguration shouldn't be able to renumber it.
> 

+1

> -Ben
> 

Re: IPv6 fc00::/7 - Unique local addresses

[Ben Jencks]

On Tue, Nov 2, 2010 at 00:58, David Conrad  wrote:
> On Nov 1, 2010, at 6:42 PM, Nathan Eisenberg wrote:
>>> My guess is that the millions of residential users will be less and
>>> less enthused with (pure) PA each time they change service providers...
>> That claim seems to be unsupported by current experience.   Please elaborate.
>
> Currently, most residential customers have PA+NATv4, where the CPE provides 
> the public IPv4 address to the NATv4 box (which might be the same box as the 
> CPE) via DHCP (or PPPoE). As such, all internal devices are shielded from all 
> renumbering events.  In a NATless PA world, all devices will need to be 
> renumbered on a change of provider.  While in theory, address lifetimes and 
> multiple addresses should reduce the impact renumbering might have, I will 
> admit some skepticism that renumbering IPv6 providers will be sufficiently 
> transparent as customers are used to with IPv4 PA+NATv4. Perhaps I am wrong.

No "average residential user" should ever see or configure an IPv6
address; all the vendors are using zeroconf etc. to avoid it at all
costs. If it was all autoconfigured in the first place, there's no
reason autoconfiguration shouldn't be able to renumber it.

-Ben

Re: IPv6 fc00::/7 - Unique local addresses

[David Conrad]

On Nov 1, 2010, at 6:42 PM, Nathan Eisenberg wrote:
>> My guess is that the millions of residential users will be less and
>> less enthused with (pure) PA each time they change service providers...
> That claim seems to be unsupported by current experience.   Please elaborate.

Currently, most residential customers have PA+NATv4, where the CPE provides the 
public IPv4 address to the NATv4 box (which might be the same box as the CPE) 
via DHCP (or PPPoE). As such, all internal devices are shielded from all 
renumbering events.  In a NATless PA world, all devices will need to be 
renumbered on a change of provider.  While in theory, address lifetimes and 
multiple addresses should reduce the impact renumbering might have, I will 
admit some skepticism that renumbering IPv6 providers will be sufficiently 
transparent as customers are used to with IPv4 PA+NATv4. Perhaps I am wrong.

Regards,
-drc

RE: IPv6 fc00::/7 - Unique local addresses

[Nathan Eisenberg]

> My guess is that the millions of residential users will be less and
> less enthused with (pure) PA each time they change service providers...

That claim seems to be unsupported by current experience.   Please elaborate.
 
Nathan

Re: IPv6 fc00::/7 — Unique local addresses

[David Conrad]

On Nov 1, 2010, at 5:23 PM, Karl Auer wrote:
> It's not a one size fits all situation.

Right.  There are folks who are more than happy (in fact demand) to pay the 
RIRs for PI space and pay their ISPs to get that space routed.  There are 
(probably) folks who are perfectly happy with PA and accept that they'll need 
to renumber all their devices and change all their configs where there are IPv6 
literals.  But my impression is that there are more people who want to minimize 
the costs associated with PI _and_ with renumbering, hence PA+ULA+NAT66.  As 
far as I can tell, the cost/benefit calculations here isn't significantly 
different from what it was with IPv4 ("96 bits, no magic"). 

> Whatever; a useful side effect of the fees is that they provide a
> barrier to the uptake of PI by smaller organisations.

Are those fees that much more of a deterrent than what ISPs will charge to 
route the PI space?

> Only those who can
> justify the cost of PI (in whatever terms that make sense to them) will
> go that way, and that will probably not be the many millions of
> residential users, who will be quite happy to use PA.

My guess is that the millions of residential users will be less and less 
enthused with (pure) PA each time they change service providers... 

Regards,
-drc

Re: IPv6 fc00::/7 — Unique local addresses

[Karl Auer]

On Mon, 2010-11-01 at 20:03 -0700, Owen DeLong wrote:
> Interesting... I guess controlling your own internet fate hasn't been a 
> priority for the companies where you've worked. Not one of my clients
> or the companies I have worked for has even given a second thought
> to approving the cost of address space once I presented the tradeoffs
> of PA vs. PI.

You know how you complained when someone moved the discourse to
residential when you mentioned enterprise and to enterprise when you
mentioned residential? At least I think it was you. Well, you're doing
it now :-)

It's not a one size fits all situation. There is no problem with some
people (typically "enterprise" types) being concerned about PI vs PA and
going one way, and someone else (typically "residential" types) not
being concerned about it and going another way. It's not really about
size, it's about the needs of the particular organisation (with
residential users just being very small organisations).

> The fees are not there to keep routes down. The fees are there to help
> the RIR recover the cost of maintaining the RIR and processing the
> application.

Whatever; a useful side effect of the fees is that they provide a
barrier to the uptake of PI by smaller organisations. Only those who can
justify the cost of PI (in whatever terms that make sense to them) will
go that way, and that will probably not be the many millions of
residential users, who will be quite happy to use PA.

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)   +61-2-64957160 (h)
http://www.biplane.com.au/kauer/   +61-428-957160 (mob)

GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF


signature.asc
Description: This is a digitally signed message part

Re: IPv6 fc00::/7 — Unique local addresses

[David Conrad]

Owen,

On Nov 1, 2010, at 4:59 PM, Owen DeLong wrote:
> Yes, one time.
> 
> Truly one time.
> 
> No other fees.

Let's say you returned all your IPv4 address space.

What would happen if you then stopped paying?

Regards,
-drc

Re: IPv6 fc00::/7 — Unique local addresses

[Owen DeLong]

On Nov 1, 2010, at 4:12 PM, Randy Bush wrote:

>>> It cost me $625 (or possibly less) one-time when I first got it.
> 
> one time?  truely one time?  no other fees or strings?
> 
> randy

Yes, one time.

Truly one time.

No other fees. The $100/year I was already paying for my other resources
covers it, so, no increase in annual fees. If you're starting from scratch, then
there is a $100/year fee.

As to strings, well, it's subject to policy like any other RIR issued addresses.
I don't see that as a problem or really as a string, but, some might.

Owen

Re: IPv6 fc00::/7 — Unique local addresses

[Owen DeLong]

On Nov 1, 2010, at 4:19 PM, Karl Auer wrote:

> On Mon, 2010-11-01 at 15:26 -0700, Jeroen van Aart wrote:
>> Karl Auer wrote:
>>> 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.
>> 
>> That seems to be quite an argument against trying to get IPv6 GUA, or am 
>> I missing something?
> 
Interesting... I guess controlling your own internet fate hasn't been a 
priority for the companies where you've worked. Not one of my clients
or the companies I have worked for has even given a second thought
to approving the cost of address space once I presented the tradeoffs
of PA vs. PI.

Depending on your meaning of non-corporate (e.g. non-business or
just not large business since this is unclear from your meaning and
corporations come in all sizes including a single person), this may
or may not be true.

> No you're not missing anything. And this is a good, simple policy tool
> to keep the numbers of PI routes down. At least from the US. But similar
> fees seem to be in force at other RIRs like APNIC and RIPE.
> 
The fees are not there to keep routes down. The fees are there to help
the RIR recover the cost of maintaining the RIR and processing the
application.

Frankly, if we simplified the approval process we could probably lower
the cost of reviewing these applications and thus lower the fees.

Owen

Re: IPv6 fc00::/7 — Unique local addresses

[Karl Auer]

On Mon, 2010-11-01 at 15:26 -0700, Jeroen van Aart wrote:
> Karl Auer wrote:
> > 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.
> 
> That seems to be quite an argument against trying to get IPv6 GUA, or am 
> I missing something?

No you're not missing anything. And this is a good, simple policy tool
to keep the numbers of PI routes down. At least from the US. But similar
fees seem to be in force at other RIRs like APNIC and RIPE.

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)   +61-2-64957160 (h)
http://www.biplane.com.au/kauer/   +61-428-957160 (mob)

GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF


signature.asc
Description: This is a digitally signed message part

Re: IPv6 fc00::/7 — Unique local addresses

[Randy Bush]

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

one time?  truely one time?  no other fees or strings?

randy

Re: IPv6 fc00::/7 — Unique local addresses

[Jeroen van Aart]

Karl Auer wrote:

On Thu, 2010-10-21 at 18:48 -0700, Owen DeLong wrote:

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.


That seems to be quite an argument against trying to get IPv6 GUA, or am 
I missing something? In my experience companies are often too cheap to 
even buy things like a software license, if the free product suffices. 
Often ignoring the hidden costs of dealing with a restricted free copy.


So I'd say, that in my case, providing an internal IPv6 network for 
testing purposes, does not warrant getting GUAs. Even if it technically 
speaking is a "good thing", it's not likely to happen.


Regards,
Jeroen

--
http://goldmark.org/jeff/stupid-disclaimers/
http://linuxmafia.com/~rick/faq/plural-of-virus.html

Re: IPv6 fc00::/7 — Unique local addresses

[Owen DeLong]

On Oct 21, 2010, at 8:25 PM, Mark Andrews wrote:

> 
> In message <4bc01459-b53a-4b2c-b75b-47d89550d...@delong.com>, Owen DeLong 
> write
> s:
>> 
>> On Oct 21, 2010, at 3:15 PM, Mark Andrews wrote:
>> 
>>> =20
>>> In message , 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.
> 
If it's all SLAAC, you're right. Most people have some servers and
some other machines that get static addresses. In those cases, those
machines have to be touched to facilitate the transition if you start with
ULA. If you start with GUA, then, it's just a matter of changing the firewall
policies and the router filters, and, possibly some routes.

> 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.
> 
We can agree to disagree about that. However, there's enough code out
there already that isn't on by default that I think that ship has sailed.


Owen

RE: IPv6 fc00::/7 ??? Unique local addresses

[George Bonser]

> 
> Coming across Phil Dykstra's paper from 1999 is what got me thinking
> about it (well, that and moving a lot of data between Europe and the
> West coast of the US).
> 
> http://sd.wareonearth.com/~phil/jumbo.html
> 
> http://staff.psc.edu/mathis/MTU/
> 
> 

Found more good information here:

http://noc.net.internet2.edu/i2network/maps--documentation/policy-statem
ents.html#Jumbo%20Frames

It might not be a bad idea to take some of what is learned on Inet2 and
backport it to the 'net where possible.  I also discovered that Linux
will do RFC4821 PMTU discovery if you set
/proc/sys/net/ipv4/tcp_mtu_probing to the proper value. It is turned off
by default.

Solaris is on by default it appears.

RE: IPv6 fc00::/7 ??? Unique local addresses

[George Bonser]

> 
> I've had pretty good luck asking for higher MTU's on both customer and
> peering links.  I'd say about an 80% success rate for dedicated
GigE's.
> It's generally not on the forms though, and sometimes you get what I
> consider weird responses.  For instance I know several providers who
> won't going higher than 4470 on ethernet.
> 
> If more folks asked for higher MTUs it might become part of the
> standard forms...

That is what I am thinking as well.  For example, in the past week I
have seen someone here asking about data center locations and mentioned
data replication between them.  If you are on both coasts of the US and
are backing up or otherwise replicating data between the two, even going
to a MTU of 3000 is a measurable win depending on the amount of data you
are moving and the protocols you are using.  Load on routers and even
hosts is generally caused by packets per second, not bits per second.
If you cut the number of packets in half you reduce the load on every
single piece of gear in the path.  Gee, I wonder how much energy
consumption that would save on a global basis if everyone did that.

Coming across Phil Dykstra's paper from 1999 is what got me thinking
about it (well, that and moving a lot of data between Europe and the
West coast of the US).

http://sd.wareonearth.com/~phil/jumbo.html

http://staff.psc.edu/mathis/MTU/

RE: IPv6 fc00::/7 ??? Unique local addresses

[George Bonser]

> Probably no reason at all, though probably little perceived benefit.
> 1492 is common enough that google/youtube already runs lower MTU's
just
> to avoid common broken PPPoE setups (which often could run higher MTU,
> but weren't configured that way).

I run into that already with people doing various things inside their
net (MPLS, GRE, IPIP?) that shorten the effective MTU but they block the
ICMP unreachable packets and break PMTU discovery.  That blanket
blocking of ICMP unreachable type 3 code 4 is evil, in my opinion.

If your traffic passes through a Cisco ASA series device (and maybe
other vendors, too) your MTU is effectively 1380 anyway as that is the
maximum MSS that it advertises (or can even be configured to advertise)
when it establishes an outbound connection and in some versions of its
code will drop a packet from an endpoint that doesn't honor the
advertised MSS.

It is a real performance killer across the Internet in my opinion and
better performance could be had, particularly for long distance links
where you are limited by the number of "in flight" packets if those
packets could be bigger. The problem is that even if you have two end
points that are jumbo capable, the networks in the path don't seem to
support >1500 MTU.  If everyone configured their peering and internal
gear to support a 9216 byte frame size and set their MTUs to 9000, that
change would be transparent to the connections flowing though it and
people who wanted to send larger frames could do so without impacting
anyone using a shorter size.

Re: IPv6 fc00::/7 ??? Unique local addresses

[Leo Bicknell]

In a message written on Sun, Oct 24, 2010 at 11:09:28AM -0500, Jack Bates wrote:
> variety of tags/tunnels/etc by the time it gets to the cell phone.  It 
> cracks me up that SONET interfaces default 4470, and ethernet still 
> defaults to 1500. I've yet to see an MTU option in standard circuit 
> setup forms, which would indicate to me that asking for a higher MTU 
> might get me one extra link before dropping back to 1500ish.

I've had pretty good luck asking for higher MTU's on both customer
and peering links.  I'd say about an 80% success rate for dedicated
GigE's.  It's generally not on the forms though, and sometimes you
get what I consider weird responses.  For instance I know several
providers who won't going higher than 4470 on ethernet.

If more folks asked for higher MTUs it might become part of the standard
forms...
-- 
   Leo Bicknell - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/


pgp9DeON8saIA.pgp
Description: PGP signature

Re: IPv6 fc00::/7 ??? Unique local addresses

[Jack Bates]

On 10/24/2010 5:05 AM, George Bonser wrote:


And speaking of changing MTU, is there any reason why private exchanges
shouldn't support jumbo frames? Is there any reason nowadays that things
that are ethernet end to end can't be MTU 9000 instead of 1500?  It
certainly would improve performance and reduce the packets/sec and
increase performance on latent links.  Why are we still using 1500 MTU
when peering?  Is there any gear at peering points that DOESN'T support
jumbo frames these days?


Probably no reason at all, though probably little perceived benefit. 
1492 is common enough that google/youtube already runs lower MTU's just 
to avoid common broken PPPoE setups (which often could run higher MTU, 
but weren't configured that way).


Not uncommon for cell companies to request 1600 MTU or more for their 
layer 2 transport, which one vendor had to custom patch 1648 into their 
gear to even support that much. Of course, it will be lowered by a 
variety of tags/tunnels/etc by the time it gets to the cell phone.  It 
cracks me up that SONET interfaces default 4470, and ethernet still 
defaults to 1500. I've yet to see an MTU option in standard circuit 
setup forms, which would indicate to me that asking for a higher MTU 
might get me one extra link before dropping back to 1500ish.


Jack

Re: IPv6 fc00::/7 ??? Unique local addresses

[Owen DeLong]

On Oct 24, 2010, at 6:48 AM, Leo Bicknell wrote:

> In a message written on Sat, Oct 23, 2010 at 05:23:14PM -0700, Owen DeLong 
> wrote:
>> On Oct 23, 2010, at 8:03 AM, Carlos Martinez-Cagnazzo wrote:
>>> On Fri, Oct 22, 2010 at 11:38 AM, Leo Bicknell  wrote:
 There are some folks (like me) who advocate a DHCPv6 that can convey
 a default gateway AND the ability to turn off RA's entirely.  That
 is make it work like IPv4.
 
>>> I'd also love to turn off stateless autoconfig altogether and not be coerced
>>> to assign /64s to single LANs, which I am becoming convinced that it was a
>>> poor decision on the IETFs part.
>>> 
>> Nah... The /64 thing is fine. If they hadn't done that, we likely would have 
>> only
>> a 64-bit address space total.  64-bit lans with 64-bit routing identifiers 
>> are
>> fine.
> 
> I think the 64-bit boundry is fine (from a DHCP perspective).  I
> do think if we're going to update the DHCP spec it should support
> a netmask option, just because leaving it out is short sighted to
> the future, but I would use it with /64's today.
> 
My understanding was DHCPv6 did support prefixes other than /64.

>> There really is no need for anything smaller than /64.  What, exactly, do you
>> think you gain from a smaller netmask?
> 
> There is a slippery slope here, if users make do with smaller
> providers may give out smaller blocks, and so on.
> 
Yeah, that could be worse than neutral. Still there's no gain to smaller
than /64, only loss...

> That said, if a provider does hand out a /64, I would very much
> like technology to make 16 bits of subnet + 48 bits of host, with
> EUI-48 used directly for autoconf as an option.  Particularly when
> we talk about 6rd and other things that use a lot of space this
> option would be huge.  Users would still get 16 bits of subnet, and
> host space so big they could never fill it.
> 
I think that ship has pretty well sailed, but, it might be a good future
workaround if providers start doing stupid pet tricks like assigning
single /64s to end customers.

Owen

Re: IPv6 fc00::/7 ??? Unique local addresses

[Leo Bicknell]

In a message written on Sat, Oct 23, 2010 at 05:23:14PM -0700, Owen DeLong 
wrote:
> On Oct 23, 2010, at 8:03 AM, Carlos Martinez-Cagnazzo wrote:
> > On Fri, Oct 22, 2010 at 11:38 AM, Leo Bicknell  wrote:
> >> There are some folks (like me) who advocate a DHCPv6 that can convey
> >> a default gateway AND the ability to turn off RA's entirely.  That
> >> is make it work like IPv4.
> >> 
> > I'd also love to turn off stateless autoconfig altogether and not be coerced
> > to assign /64s to single LANs, which I am becoming convinced that it was a
> > poor decision on the IETFs part.
> > 
> Nah... The /64 thing is fine. If they hadn't done that, we likely would have 
> only
> a 64-bit address space total.  64-bit lans with 64-bit routing identifiers are
> fine.

I think the 64-bit boundry is fine (from a DHCP perspective).  I
do think if we're going to update the DHCP spec it should support
a netmask option, just because leaving it out is short sighted to
the future, but I would use it with /64's today.

> There really is no need for anything smaller than /64.  What, exactly, do you
> think you gain from a smaller netmask?

There is a slippery slope here, if users make do with smaller
providers may give out smaller blocks, and so on.

That said, if a provider does hand out a /64, I would very much
like technology to make 16 bits of subnet + 48 bits of host, with
EUI-48 used directly for autoconf as an option.  Particularly when
we talk about 6rd and other things that use a lot of space this
option would be huge.  Users would still get 16 bits of subnet, and
host space so big they could never fill it.

-- 
   Leo Bicknell - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/


pgp2bo6xSqqM8.pgp
Description: PGP signature

RE: IPv6 fc00::/7 ??? Unique local addresses

[George Bonser]

> 
> What would be nice would be if we changed the semantics a bit and made
> it 16+48+64 where the first 16 of the dest+source could be
re-assembled
> into the destination ASN for the packet and the remaining 48
identified
> a particular subnet globally with 64 for the host. Unfortunately, that
> ship
> has probably sailed.

On the other hand, it probably would have been easier (and more widely
adopted already) to simply go to an "internet of internets" model where
you break the planet up into 32-bit regions, each with their own 32-bit
"internets" and just use what amounts to IPIP tunneling between them and
enlarge the standard MTU from 1500 to accommodate that without further
packet fragmentation.

And speaking of changing MTU, is there any reason why private exchanges
shouldn't support jumbo frames? Is there any reason nowadays that things
that are ethernet end to end can't be MTU 9000 instead of 1500?  It
certainly would improve performance and reduce the packets/sec and
increase performance on latent links.  Why are we still using 1500 MTU
when peering?  Is there any gear at peering points that DOESN'T support
jumbo frames these days?

RE: IPv6 fc00::/7 ??? Unique local addresses

[George Bonser]

> 
> What would be nice would be if we changed the semantics a bit and made
> it 16+48+64 where the first 16 of the dest+source could be
re-assembled
> into the destination ASN for the packet and the remaining 48
identified
> a particular subnet globally with 64 for the host. Unfortunately, that
> ship
> has probably sailed.

Well, since ASNs are now 32-bit, yeah.

Re: IPv6 fc00::/7 ??? Unique local addresses

[Owen DeLong]

On Oct 23, 2010, at 8:03 AM, Carlos Martinez-Cagnazzo wrote:

> Amen!
> 
> On Fri, Oct 22, 2010 at 11:38 AM, Leo Bicknell  wrote:
> 
>> 
>> There are some folks (like me) who advocate a DHCPv6 that can convey
>> a default gateway AND the ability to turn off RA's entirely.  That
>> is make it work like IPv4.
>> 
>> 
> I'd also love to turn off stateless autoconfig altogether and not be coerced
> to assign /64s to single LANs, which I am becoming convinced that it was a
> poor decision on the IETFs part.
> 
Nah... The /64 thing is fine. If they hadn't done that, we likely would have 
only
a 64-bit address space total.  64-bit lans with 64-bit routing identifiers are
fine.

What would be nice would be if we changed the semantics a bit and made
it 16+48+64 where the first 16 of the dest+source could be re-assembled
into the destination ASN for the packet and the remaining 48 identified
a particular subnet globally with 64 for the host. Unfortunately, that ship
has probably sailed.

> Stateless autoconfig works very well, It would be just perfect if the
> network boundary was configurable (like say /64 if you really want it,  or
> /80 -  /96 for the rest of us)
> 
There really is no need for anything smaller than /64.  What, exactly, do you
think you gain from a smaller netmask?

Owen

RE: IPv6 fc00::/7 ??? Unique local addresses

[Nathan Eisenberg]

> Stateless autoconfig works very well, It would be just perfect if the
> network boundary was configurable (like say /64 if you really want it,
> or
> /80 -  /96 for the rest of us)

Why do you feel it's a poor decision to assign /64's to individual LANs?

Best Regards,
Nathan Eisenberg

Re: IPv6 fc00::/7 ??? Unique local addresses

[Carlos Martinez-Cagnazzo]

Amen!

On Fri, Oct 22, 2010 at 11:38 AM, Leo Bicknell  wrote:

>
> There are some folks (like me) who advocate a DHCPv6 that can convey
> a default gateway AND the ability to turn off RA's entirely.  That
> is make it work like IPv4.
>
>
I'd also love to turn off stateless autoconfig altogether and not be coerced
to assign /64s to single LANs, which I am becoming convinced that it was a
poor decision on the IETFs part.

Stateless autoconfig works very well, It would be just perfect if the
network boundary was configurable (like say /64 if you really want it,  or
/80 -  /96 for the rest of us)

cheers

Carlos

-- 
--
=
Carlos M. Martinez-Cagnazzo
http://cagnazzo.name
=

Re: IPv6 fc00::/7 — Unique local addresses

[Owen DeLong]

On Oct 23, 2010, at 7:26 AM, Mark Smith wrote:

> On Fri, 22 Oct 2010 15:42:41 -0700
> Owen DeLong  wrote:
> 
> 
 Actually, it's not pointless at all. The RA system assumes that all routers
 capable of announcing RAs are default routers and that virtually all 
 routers
 are created equal (yes, you have high/medium/low, but, really, since you
 have to use high for everything in any reasonable deployment...)
 
>>> 
>>> No it doesn't. You can set the router lifetime to zero, which indicates
>>> to the end-node that the RA isn't announcing a default router. In this
>>> case, it may be announcing M/O bit, prefix or other parameters.
>>> 
>> DHCPv6 can selectively give different information to different hosts
>> on the same wire segment.
>> 
>> RA cannot.
>> 
> 
> That was not the assertion you made.
> 
> You said that 
> 
> "The RA system assumes that all routers
 capable of announcing RAs are default routers"
> 
> and I said, no, that is not the case if you set the RA lifetime to
> zero. To cite explicitly, RFC4861 says,
> 
Right... I oversimplified the point I was attempting to make and you
called me on it... Move on.

>  Router Lifetime
> 16-bit unsigned integer.  The lifetime associated
> with the default router in units of seconds.  The
> field can contain values up to 65535 and receivers
> should handle any value, while the sending rules in
> Section 6 limit the lifetime to 9000 seconds.  A
> Lifetime of 0 indicates that the router is not a
> default router and SHOULD NOT appear on the default
> 
> 
> 
> Narten, et al.  Standards Track[Page 20]
> ^L
> RFC 4861   Neighbor Discovery in IPv6 September 2007
> 
> 
> router list.  The Router Lifetime applies only to
> the router's usefulness as a default router; it
> does not apply to information contained in other
> message fields or options.  Options that need time
> limits for their information include their own
> lifetime fields.
> 
> 
> I was not making any statements about whether DHCPv6 could be
> selective about providing certain options to selected end-nodes.
> 
> You might think I'm being overlay pedantic, however changing the
> question to then disagree with answer that doesn't agree with yours is
> being disingenuous. 
> 
 There are real environments where it's desirable to have a way to tell
 different clients on a network to use different default gateways or
 default gateway sets.
 
> 
> I wouldn't necessarily disagree, although in my experience they're
> really quite rare, to the point where segmenting them into a separate
> subnet, via e.g. a different VLAN, becomes a somewhat better and easier
> option.
> 
While I would agree with you operationally, sometimes they involve
software that discovers other devices by broadcast and does not
permit other mechanisms.

I've seen environments where they're able to deal with this in IPv4
because of this flexibility in DHCPv4 and would be limited to static
addressing in IPv6 because it lacks this ability.

Owen

Re: IPv6 fc00::/7 — Unique local addresses

[Mark Smith]

On Fri, 22 Oct 2010 15:42:41 -0700
Owen DeLong  wrote:

> >>> 
> >> Actually, it's not pointless at all. The RA system assumes that all routers
> >> capable of announcing RAs are default routers and that virtually all 
> >> routers
> >> are created equal (yes, you have high/medium/low, but, really, since you
> >> have to use high for everything in any reasonable deployment...)
> >> 
> > 
> > No it doesn't. You can set the router lifetime to zero, which indicates
> > to the end-node that the RA isn't announcing a default router. In this
> > case, it may be announcing M/O bit, prefix or other parameters.
> > 
> DHCPv6 can selectively give different information to different hosts
> on the same wire segment.
> 
> RA cannot.
> 

That was not the assertion you made.

You said that 

"The RA system assumes that all routers
> >> capable of announcing RAs are default routers"

and I said, no, that is not the case if you set the RA lifetime to
zero. To cite explicitly, RFC4861 says,

  Router Lifetime
 16-bit unsigned integer.  The lifetime associated
 with the default router in units of seconds.  The
 field can contain values up to 65535 and receivers
 should handle any value, while the sending rules in
 Section 6 limit the lifetime to 9000 seconds.  A
 Lifetime of 0 indicates that the router is not a
 default router and SHOULD NOT appear on the default



Narten, et al.  Standards Track[Page 20]
^L
RFC 4861   Neighbor Discovery in IPv6 September 2007


 router list.  The Router Lifetime applies only to
 the router's usefulness as a default router; it
 does not apply to information contained in other
 message fields or options.  Options that need time
 limits for their information include their own
 lifetime fields.


I was not making any statements about whether DHCPv6 could be
selective about providing certain options to selected end-nodes.

You might think I'm being overlay pedantic, however changing the
question to then disagree with answer that doesn't agree with yours is
being disingenuous. 

> >> There are real environments where it's desirable to have a way to tell
> >> different clients on a network to use different default gateways or
> >> default gateway sets.
> >>

I wouldn't necessarily disagree, although in my experience they're
really quite rare, to the point where segmenting them into a separate
subnet, via e.g. a different VLAN, becomes a somewhat better and easier
option.

Regards,
Mark.

Re: IPv6 fc00::/7 ? Unique local addresses

[Daniel Roesen]

On Fri, Oct 22, 2010 at 08:55:49AM -0500, Jack Bates wrote:
>> I suppose you could run DHCPv6 on a subnet to give hosts addresses
>> but never give them a default gateway, but that would be a little
>> useless no?
>
> Works great when you don't need routing.

Or the default route should point out a different interface.

Think e.g. of DHCP used for a management network. You don't want a
default route, but in case of a routed management network, signal a
set of specific routes.

http://tools.ietf.org/html/draft-dec-dhcpv6-route-option-05, there
we go.

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: d...@cluenet.de -- d...@ircnet -- PGP: 0xA85C8AA0

Re: IPv6 fc00::/7 — Unique local addresses

[Owen DeLong]

>>> 
>> Actually, it's not pointless at all. The RA system assumes that all routers
>> capable of announcing RAs are default routers and that virtually all routers
>> are created equal (yes, you have high/medium/low, but, really, since you
>> have to use high for everything in any reasonable deployment...)
>> 
> 
> No it doesn't. You can set the router lifetime to zero, which indicates
> to the end-node that the RA isn't announcing a default router. In this
> case, it may be announcing M/O bit, prefix or other parameters.
> 
DHCPv6 can selectively give different information to different hosts
on the same wire segment.

RA cannot.

>> There are real environments where it's desirable to have a way to tell
>> different clients on a network to use different default gateways or
>> default gateway sets.
>> 
>> Owen
>> 

Re: IPv6 fc00::/7 — Unique local addresses

[Karl Auer]

On Sat, 2010-10-23 at 03:48 +1030, Mark Smith wrote:
> An RA is single, periodic, in the order of 100s of seconds, multicast
> packet. If you're arguing against the cost of that, then I think you're
> being a bit too precious with your packets.

Just to be clear on this: I was taking issue solely with the idea that
DHCPv6 requires RA. It doesn't.

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)   +61-2-64957160 (h)
http://www.biplane.com.au/kauer/   +61-428-957160 (mob)

GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF


signature.asc
Description: This is a digitally signed message part

Re: IPv6 fc00::/7 — Unique local addresses

[Mark Smith]

On Fri, 22 Oct 2010 01:10:08 -0700
Owen DeLong  wrote:

> 
> On Oct 22, 2010, at 12:55 AM, Mark Smith wrote:
> 
> > On Fri, 22 Oct 2010 15:52:08 +1100
> > Karl Auer  wrote:
> > 
> >> On Thu, 2010-10-21 at 21:05 -0500, Jack Bates wrote:
> >>> On 10/21/2010 8:39 PM, Ray Soucy wrote:
>  
>  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...
> >>> 
> >>> Actually, the last I checked, there are implementation of DHCPv6 without 
> >>> RA.
> >> 
> >> I'll go out on a limb here and say that RA is not needed for DHCPv6.
> >> 
> > 
> > RAs are still needed to convey the M/O bit values, so that end-nodes
> > know they need to use DHCPv6 if necessary. As there are two address
> > configuration methods, there is always going to be a need to express a
> > policy to end-nodes as to which one they need to use.
> > 
> You can actually force a client to assume the M bit if you cause it to launch
> a DHCPv6 client through other means. You don't have to have RA for that.
> Policy can be expressed by RA, or, it can be expressed by other means.
> 

We used to hand wind cars to start them. We don't have to anymore.

An RA is single, periodic, in the order of 100s of seconds, multicast
packet. If you're arguing against the cost of that, then I think you're
being a bit too precious with your packets.

Any argument for manual configuration is an argument for increasing
complexity and opportunity for error.


> >> 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.
> >> 
> > 
> > There isn't a method to specify a default gateway in DHCPv6. Some
> > people want it, however it seems a bit pointless to me if you're going
> > to have RAs announcing M/O bits anyway - you may as well use those RAs
> > to announce a default router too.
> > 
> Actually, it's not pointless at all. The RA system assumes that all routers
> capable of announcing RAs are default routers and that virtually all routers
> are created equal (yes, you have high/medium/low, but, really, since you
> have to use high for everything in any reasonable deployment...)
> 

No it doesn't. You can set the router lifetime to zero, which indicates
to the end-node that the RA isn't announcing a default router. In this
case, it may be announcing M/O bit, prefix or other parameters.

> There are real environments where it's desirable to have a way to tell
> different clients on a network to use different default gateways or
> default gateway sets.
> 
> Owen
> 

Re: IPv6 fc00::/7 ??? Unique local addresses

[Matthew Petach]

On Fri, Oct 22, 2010 at 7:06 AM, Jack Bates  wrote:
> On 10/22/2010 8:38 AM, Leo Bicknell wrote:
>>
>> Unfortunately the folks in the IETF don't even want to listen, to the
>> point a working group chair when I tried to explain why I wanted such a
>> feater told the rest of the group "He's an operator and thus doesn't
>> understand how any of this works, ignore him."  That's when I gave up
>> on the IETF, and started working on my vendor for the solution.
>>
> It's popped around multiple times. The drafts won't stop until it's
> implemented. The lack of it in DHCPv6, despite obvious desire for it, seems
> to indicate a bias on the part of the IETF.

The interesting thing is that while the IETF may  have a certain bias, the
hardware manufacturers have a different bias; they do what needs to be
done to sell hardware.  And while we may be 'just operators', if we tell
vendors we won't buy their hardware unless they support draft-X-Y-Z,
you can believe they'll listen to that a lot more closely than they will
the IETF.

The IETF has teeth only so long as those with money to spend on
vendors support their decisions.  When a vendor is forced to choose
between complying with the IETF, or getting a $5M purchase order
from a customer, they're going to look long and hard at what the
customer is requesting.  We've gotten knobs added to software
that go explicitly against standards that way; they're off by default,
they're hidden, and they have ugly names like "enable
broken-ass-feature-for-customer-X"
but the vendors *do* put them in, because without them, they don't
get paid.

Matt

> Here's a current draft
> http://tools.ietf.org/html/draft-dec-dhcpv6-route-option-05
>
> Jack

Re: IPv6 fc00::/7 ??? Unique local addresses

[Jack Bates]

On 10/22/2010 8:38 AM, Leo Bicknell wrote:

Unfortunately the folks in the IETF don't even want to listen, to the
point a working group chair when I tried to explain why I wanted such a
feater told the rest of the group "He's an operator and thus doesn't
understand how any of this works, ignore him."  That's when I gave up
on the IETF, and started working on my vendor for the solution.



It's popped around multiple times. The drafts won't stop until it's 
implemented. The lack of it in DHCPv6, despite obvious desire for it, 
seems to indicate a bias on the part of the IETF.


Here's a current draft 
http://tools.ietf.org/html/draft-dec-dhcpv6-route-option-05


Jack

Re: IPv6 fc00::/7 ??? Unique local addresses

[Leo Bicknell]

In a message written on Fri, Oct 22, 2010 at 06:25:18PM +1030, Mark Smith wrote:
> There isn't a method to specify a default gateway in DHCPv6. Some
> people want it, however it seems a bit pointless to me if you're going
> to have RAs announcing M/O bits anyway - you may as well use those RAs
> to announce a default router too.

There are some folks (like me) who advocate a DHCPv6 that can convey
a default gateway AND the ability to turn off RA's entirely.  That
is make it work like IPv4.

There are pros, and cons; but I can think of a number of deployment
scenarios where it would be a vast improvement and beleive strongly
operators should have the choice.

Unfortunately the folks in the IETF don't even want to listen, to the
point a working group chair when I tried to explain why I wanted such a
feater told the rest of the group "He's an operator and thus doesn't
understand how any of this works, ignore him."  That's when I gave up
on the IETF, and started working on my vendor for the solution.

-- 
   Leo Bicknell - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/


pgpWjOAKfB645.pgp
Description: PGP signature

Re: IPv6 fc00::/7 — Unique local addresses

[Ray Soucy]

The design of IPv6 is that DHCPv6 and RA work together.  This is why
there is no method to express the default gateway using DHCPv6, that
task is handled by the RA.  I suppose you could run DHCPv6 on a subnet
to give hosts addresses but never give them a default gateway, but
that would be a little useless no?

Please stop confusing people about DHCPv6.  There is already enough
misinformation out there.

It's starting to feel like Fox News here, next there will be another
post citing yours saying "experts on NANOG have said that DHCPv6
doesn't require RA" and make users spend hours looking for how to set
the gateway address.

On Thu, Oct 21, 2010 at 10:05 PM, Jack Bates  wrote:
> On 10/21/2010 8:39 PM, Ray Soucy wrote:
>>
>> 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...
>
> Actually, the last I checked, there are implementation of DHCPv6 without RA.
>
>
> Jack
>
>



-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/

Re: IPv6 fc00::/7 — Unique local addresses

[Owen DeLong]

On Oct 22, 2010, at 12:55 AM, Mark Smith wrote:

> On Fri, 22 Oct 2010 15:52:08 +1100
> Karl Auer  wrote:
> 
>> On Thu, 2010-10-21 at 21:05 -0500, Jack Bates wrote:
>>> On 10/21/2010 8:39 PM, Ray Soucy wrote:
 
 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...
>>> 
>>> Actually, the last I checked, there are implementation of DHCPv6 without RA.
>> 
>> I'll go out on a limb here and say that RA is not needed for DHCPv6.
>> 
> 
> RAs are still needed to convey the M/O bit values, so that end-nodes
> know they need to use DHCPv6 if necessary. As there are two address
> configuration methods, there is always going to be a need to express a
> policy to end-nodes as to which one they need to use.
> 
You can actually force a client to assume the M bit if you cause it to launch
a DHCPv6 client through other means. You don't have to have RA for that.
Policy can be expressed by RA, or, it can be expressed by other means.

>> 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.
>> 
> 
> There isn't a method to specify a default gateway in DHCPv6. Some
> people want it, however it seems a bit pointless to me if you're going
> to have RAs announcing M/O bits anyway - you may as well use those RAs
> to announce a default router too.
> 
Actually, it's not pointless at all. The RA system assumes that all routers
capable of announcing RAs are default routers and that virtually all routers
are created equal (yes, you have high/medium/low, but, really, since you
have to use high for everything in any reasonable deployment...)

There are real environments where it's desirable to have a way to tell
different clients on a network to use different default gateways or
default gateway sets.

Owen

Re: IPv6 fc00::/7 — Unique local addresses

[Mark Smith]

On Fri, 22 Oct 2010 15:52:08 +1100
Karl Auer  wrote:

> On Thu, 2010-10-21 at 21:05 -0500, Jack Bates wrote:
> > On 10/21/2010 8:39 PM, Ray Soucy wrote:
> > >
> > > 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...
> > 
> > Actually, the last I checked, there are implementation of DHCPv6 without RA.
> 
> I'll go out on a limb here and say that RA is not needed for DHCPv6.
> 

RAs are still needed to convey the M/O bit values, so that end-nodes
know they need to use DHCPv6 if necessary. As there are two address
configuration methods, there is always going to be a need to express a
policy to end-nodes as to which one they need to use.

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

There isn't a method to specify a default gateway in DHCPv6. Some
people want it, however it seems a bit pointless to me if you're going
to have RAs announcing M/O bits anyway - you may as well use those RAs
to announce a default router too.

Regards,
Mark.

Re: IPv6 fc00::/7 — Unique local addresses

[Mikael Abrahamsson]

On Fri, 22 Oct 2010, Karl Auer wrote:

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


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

--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: IPv6 fc00::/7 — Unique local addresses

[Karl Auer]

On Thu, 2010-10-21 at 21:05 -0500, Jack Bates wrote:
> On 10/21/2010 8:39 PM, Ray Soucy wrote:
> >
> > 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...
> 
> Actually, the last I checked, there are implementation of DHCPv6 without RA.

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.

-- 
~~~
Karl Auer (ka...@biplane.com.au)   +61-2-64957160 (h)
http://www.biplane.com.au/kauer/   +61-428-957160 (mob)

GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF


signature.asc
Description: This is a digitally signed message part

Re: Re: IPv6 fc00::/7 — Unique local addresses

[Mark Andrews]

In message , 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.

> > 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
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: IPv6 fc00::/7 — Unique local addresses

[Karl Auer]

On Thu, 2010-10-21 at 18:48 -0700, Owen DeLong wrote:
> 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 :-)

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

Regards, K.

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

-- 
~~~
Karl Auer (ka...@biplane.com.au)   +61-2-64957160 (h)
http://www.biplane.com.au/kauer/   +61-428-957160 (mob)

GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF


signature.asc
Description: This is a digitally signed message part

Re: Re: IPv6 fc00::/7 — Unique local addresses

[Mark Andrews]

In message <4bc01459-b53a-4b2c-b75b-47d89550d...@delong.com>, Owen DeLong write
s:
> 
> On Oct 21, 2010, at 3:15 PM, Mark Andrews wrote:
> 
> >=20
> > In message , 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.

> >=20
> Owen
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: IPv6 fc00::/7 - Unique local addresses

[Mark Andrews]

In message <3d230c80-e7cc-4b73-9e47-780df5fa3...@delong.com>, Owen DeLong write
s:
> 
> On Oct 21, 2010, at 4:48 PM, Karl Auer wrote:
> 
> > On Fri, 2010-10-22 at 10:10 +1100, Skeeve Stevens wrote:
> >> 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. ;-)

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

> Owen
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: IPv6 fc00::/7 - Unique local addresses

[Owen DeLong]

On Oct 21, 2010, at 4:48 PM, Karl Auer wrote:

> On Fri, 2010-10-22 at 10:10 +1100, Skeeve Stevens wrote:
>> 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. ;-)

Owen

Re: IPv6 fc00::/7 — Unique local addresses

[Owen DeLong]

On Oct 21, 2010, at 3:59 PM, Karl Auer wrote:

> On Thu, 2010-10-21 at 01:46 -0700, Owen DeLong wrote:
>>> 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

Re: IPv6 fc00::/7 — Unique local addresses

[Owen DeLong]

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

Re: IPv6 fc00::/7 — Unique local addresses

[Ray Soucy]

(Response inline).

On Thu, Oct 21, 2010 at 9:01 PM, Owen DeLong  wrote:
>> 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.

-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/

Re: IPv6 fc00::/7 — Unique local addresses

[Owen DeLong]

On Oct 21, 2010, at 3:15 PM, Mark Andrews wrote:

> 
> In message , Owen DeLong 
> write
> s:
> 
 Which is part one of the three things that have to happen to make ULA
 really bad for the internet.
 
 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.
 
>>> 
>>> 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.
>>> 
>> _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.
>> 
>> 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.
> 
> IPv4 think.
> 
> You don't re-address you add a new address to every node.  IPv6 is
> designed for multiple addresses.
> 
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.

>>> 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.
>>> 
>> 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),
> 
> 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.
> 
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.
> 
Owen

Re: IPv6 fc00::/7 - Unique local addresses

[Owen DeLong]

> 
>> They *will* fight you, and tell you to your face that if you want to
>> take NAT away from them it will be from their cold dead hands.
> 
> And it isn't NAT in and of itself that is attractive.  Those people
> aren't talking about static NAT where you are just translating the
> network prefix.  They are talking dynamic port-based PAT so that the
> translation doesn't exist until the first packet goes in the outbound
> direction.  Like it or not, that DOES provide some barrier of entry to
> someone outside wishing to initiate a connection from the outside.  You
> cannot predict in advance what outside address/port will be associated
> with which inside address/port or if any such association even exists
> and a lot of people have already made up their minds that the breakage
> that causes for various things is offset by the perceived benefit of
> that barrier and worth the price of dealing with that breakage.
> 
Ah... You've actually just pointed out that it is _NOT_ the NAT that does
that, but, the stateful inspection that happens before the NAT.

Stateful inspection can occur and require a matching state table entry
to permit inbound packets with or without the header-mangling that
we call NAT, NPAT, NAPT, PAT, etc.

True, overloaded NAT cannot exist without stateful inspection, but,
that's largely irrelevant to security. What is relevant is the need for
a good stateful inspection engine with a default-deny-inbound policy.

Owen

Re: IPv6 fc00::/7 — Unique local addresses

[Owen DeLong]

> Using multiple ISPs is still something that is a bit tricky.  A lot of
> people have gotten used to the Dual-WAN Firewall appliance boxes that
> accept connections from two ISPs and handle the failover, depending on
> NAT to maintain the functionality of the Internal network.
> 
> Larger organizations can arrange to have IPv6 transit and announce a
> single prefix over BGP.  Most providers won't want to see this setup
> for an SMB so they're out of luck.
> 
Actually, ANY size organization can do this. Most providers won't want
to set this up over native DSL, CMTS, or PON cheap circuits. There
are options there. Do BGP over tunnels using your native circuits
as L2 transport, for one. (This is working quite well for me and hasn't
been all that hard to implement).

> One thing that has changed, though, is Metro Ethernet offerings have
> gotten a lot better.  I would say the most painless way to go would be
> to use one ISP for L3, and two ME providers to give diverse L2 paths
> to that L3 ISP.  It means dealing with more companies, and moving
> failover to L2, but it's pretty rare that the cause of a connection
> problem is at the ISP these days (it's more often a bad connection
> between you and the ISP), so just having redundancy at L2 might be
> enough.
> 
I'm not convinced that's the best approach. If I were doing that, I'd use
the two metro-E connections to reach different providers and run BGP.
It's just not that hard. Especially if your BGP is accept default, advertise
_myroute_.

> Sadly, that model doesn't really exist in the US right now, and it
> might take quite a bit of work convincing providers to coordinate to
> make it all work.
> 
Another argument in favor of the L2/L3 topologies matching. 
(There are also reliability and simplicity arguments to favor
doing so).

> The other option, which was the intent of IPv6 when being designed
> (but that was 10 years ago or so) was that every PC would have a
> separate address from each ISP.  In this situation you could depend on
> ULA (local addressing) for access to all internal services so that if
> one of the global prefixes goes away it doesn't impact internal
> operation, but it does require a device to kind of coordinate that-
> such a device doesn't exist yet, and there are some issues with
> getting PCs to handle address selection correctly.  I suspect if this
> does happen (and it could, it's not a horrible model) it will take a
> few more years before it's "easy".  It's too bad they axed the site
> local scope for this kind of environment.
> 
Please stop promulgating the fiction that IPv6 addressing from your
provider depends on reachability to your provider to continue
functioning on your internal network. It simply isn't true unless
you are getting those addresses via DHCPv6 or SLAAC.
If you have a topology, SLAAC is a non-starter and it would
have to be DHCPv6-PD or static. If you have static, there's
no need whatsoever for ULA. No sane business would go for
having their IPv6 addresses delivered to them via DHCPv6-PD.

> For now, I would recommend just going with a single IPv6 provider
> since I have yet to encounter IPv6-only content that is mission
> critical.  That will at least give you access to the IPv6 internet
> now, but give the IPv6 market time to come around to meet the needs of
> SMB and wanting redundancy in IPv6 access.
> 
This is a very solvable problem to day, but, it does require a tiny
amount of training/learning to implement the solution.

> I'm not aware of any appliance that does a good job at IPv6, yet...
> 
Depends on your definition of Appliance. If you would consider
an SRX-100 an appliance, it works reasonably well. It cost less
than several of the other appliances in my house.

> If it were me I would build up a Linux box as a IPv6 firewall, router,
> etc.  It's really too bad that there isn't such an appliance yet.  You
> could just use a Cisco ISR (like an 1841) as your IPv6 on a stick
> router, but the problem is that you really want to keep in mind that
> once you give out global addresses to hosts they're not behind your
> NAT firewall for IPv6.  So you'll want to implement some sort of
> stateful firewall for IPv6, or enable host-based IPv6 firewalls.
> 
Linux box is a fine alternative, ip6tables works well, but, Linux
box vs. SRX-100, the cost difference isn't that large.

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

> 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

Re: IPv6 fc00::/7 — Unique local addresses

[Joe Hamelin]

On Thu, Oct 21, 2010 at 5:34 PM, Randy Carpenter  wrote:
> Justification aside, it is quote affordable for a typical power user.

For large values of affordable.

--
Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474

Re: IPv6 fc00::/7 — Unique local addresses

[Randy Carpenter]

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

Correction:  For endusers it is $1250 initially, and $100 per year thereafter. 
Much closer to affordable. That same $100 also covers an ASN if you have one. 
ISPs are charged the large yearly fee.

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

Justification aside, it is quote affordable for a typical power user.

-Randy

Re: IPv6 fc00::/7 - Unique local addresses

[Mark Andrews]

In message <5a6d953473350c4b9995546afe9939ee0b14c...@rwc-ex1.corp.seven.com>, "
George Bonser" writes:
> > Sent: Thursday, October 21, 2010 3:16 PM
> > To: Owen DeLong
> > Cc: NANOG list
> > Subject: Re: Re: IPv6 fc00::/7 - Unique local addresses
> >=20
> > IPv4 think.
> >=20
> > You don't re-address you add a new address to every node.  IPv6 is
> > designed for multiple addresses.
> >=20
> 
> How does your application on the host decide which address to use when
> sourcing an outbound connection if you have two different subnets that
> are globally routable?

But ULAs aren't globally routable.  ULA addresses are easy to
identify and guess what IPv6 stacks know how to select different
source address depending apon the destination address.  They also
know how to order the addresses returned to the application such
that reachable ULA's are returned first and non-reachable ULAs are
returned last.

You can do the same thing with a RIR assigned prefix for internal
communication but it requires more explict configuration.  With
ULA's the IPv6 stack can auto configure itself as you have a well
known identifier.

Any node that supports RFC3484 (February 2003) can do this for you
though you may need to override the defaults.  If your OS doesn't
yet support it complain.  The ability to set this site wide is also
coming.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: IPv6 fc00::/7 — Unique local addresses

[Owen DeLong]

On Oct 21, 2010, at 9:29 AM, Allen Smith wrote:

> Hi All,
> 
> I've inherited a small network with a couple of Internet connections through
> different providers, I'll call them Slow and Fast.
> 
> We use RFC 1918 space internally and have a pair of external firewalls that
> handle NAT and such.
> 
> Due to internal policy (read money), some users default to the Slow
> connection and some default to Fast. Using probes and policy routing, a
> failure of one of the ISPs is generally transparent, outside of the usual
> session resets for things like ssh or remote control sessions).
> 
> Looking forward to the next 12 months, we may have clients that are living
> in IPv6 space. Our ISPs are happy to give us IPv6 allocations and our
> network gear vendors either have GA IPv6 code now or will soon.
> 
> We have been somewhat spoiled by our firewall/NAT boxes, the stuff just
> works for our needs and the combination of NAT and policy routing keeps
> people on the circuits they are paying for. Am trying to decide how I would
> implement this kind of policy in the new world of globally
> trackable^H^H^H^H^H^H^H routable IPs for my desktops. Solutions seem to be:
> 
My suggestion:

1.  Get a /48 from your friendly neighborhood RIR.
2.  Get an ASN to go with it.
3.  Accept that your inbound is going to get topologically divided between
the two links rather than customer-specific.

If that's not an option, then:

1.  Get /48s from both providers.
2.  Provide appropriate RAs to your users so that the users that should 
prefer
provider SLOW get RAs with a higher preference to provider SLOW and
the users that should prefer provider FAST get RAs with a higher 
preference
for provider FAST.
3.  Update your probes/policy routing scripts so that they will deprecate 
the
broken RA (you can do this by sending a poisoned final RA with a very
short valid time to the all hosts multicast address of each subnet).

Option 3 is a very bad idea and I hope your vendor would refuse.

Owen

> 1) Purchase some BGP capable routers, grab PI space. Here I can obv choose
> outbound path, but we are typical in that our inbound to outbound is 6 or 7
> to 1.
> 

> 2) Assign PA space from the ISPs to the appropriate devices. What do I do
> when I loose a provider?
> 
> 3) Make loud noises to my firewall vendor to include equivalent NAT/ISP
> failover functionality (even 6to6 NAT would be fine).
> 
> Anyway, another sample of 1, but I do work for a managed services provider
> and see many small orgs facing similary choices. I personally am happy to
> use globally routable addresses and will work through the privacy and
> perceived security implications of NAT/nonat, I just want the same ease of
> use and flexibility I have today in a SMB environment.
> 
> Cheers,
> -Allen

Re: IPv6 fc00::/7 — Unique local addresses

[Owen DeLong]

On Oct 21, 2010, at 9:34 AM, Brandon Ross wrote:

> On Thu, 21 Oct 2010, Graham Beneke wrote:
> 
>> On 21/10/2010 03:49, Matthew Kaufman wrote:
>>> On 10/20/2010 5:51 PM, Owen DeLong wrote:
 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.
>>> Is this happening now with RFC 1918 addresses and IPv4?
>> 
>> I have seen this in some small providers. Doesn't last long since the chance 
>> of collision is high. It then becomes a VPN.
> 
> I know for a fact that an extremely large tier 1 routed RFC1918 address space 
> for an extremely large cable company at one time (and no, I don't mean 2547 
> or anything like that).  I have no idea if this is still occurring, but when 
> this very large cable company needed to use more private addresses they 
> actually would ask the tier 1 for an assignment in order to avoid collision.
> 
> I don't see the problem with ULA though, sure, someone will route it, but not 
> everyone, just those getting paid to.  It's actually the perfect solution to 
> routing table bloat as there is a financial relationship between the parties 
> that announce space and the networks that carry it.
> 
Only until there are two parties getting paid by two other parties to route it 
and they agree to exchange those routes without compensation in order to 
benefit their mutual customers who want to reach each other. From there, the 
problem mushrooms rapidly.

Owen

RE: IPv6 fc00::/7 - Unique local addresses

[Skeeve Stevens]

Small correction - there is no annual fee in the first year ;-)

But I agree.. it is too much, and APNIC have been reviewing the Initial 
allocation fee for a while now, but haven't made any move on it.

I'd like to see a new class of membership - 'Individual' which had a small 
allocation (well, in comparison) and had a cheaper membership level and was not 
required to be multi-homed, but was portable - and a small, if any initial 
allocation fee.

...Skeeve

--
Skeeve Stevens, CEO
eintellego Pty Ltd - The Networking Specialists
ske...@eintellego.net / www.eintellego.net
Phone: 1300 753 383, Fax: (+612) 8572 9954
Cell +61 (0)414 753 383 / skype://skeeve
www.linkedin.com/in/skeeve ; facebook.com/eintellego
--
eintellego - The Experts that the Experts call
- Juniper - HP Networking - Cisco - Arista -


> -Original Message-
> From: Karl Auer [mailto:ka...@biplane.com.au]
> Sent: Friday, 22 October 2010 10:48 AM
> To: nanog@nanog.org
> Subject: RE: IPv6 fc00::/7 - Unique local addresses
> 
> On Fri, 2010-10-22 at 10:10 +1100, Skeeve Stevens wrote:
> > 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.
> 
> 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.
> 
> Regards, K.
> 
> --
> ~~~
> Karl Auer (ka...@biplane.com.au)   +61-2-64957160 (h)
> http://www.biplane.com.au/kauer/   +61-428-957160 (mob)
> 
> GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
> Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF

RE: IPv6 fc00::/7 - Unique local addresses

[Karl Auer]

On Fri, 2010-10-22 at 10:10 +1100, Skeeve Stevens wrote:
> 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.

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.

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)   +61-2-64957160 (h)
http://www.biplane.com.au/kauer/   +61-428-957160 (mob)

GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF


signature.asc
Description: This is a digitally signed message part

RE: IPv6 fc00::/7 - Unique local addresses

[Skeeve Stevens]

Karl, 

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.


...Skeeve

--
Skeeve Stevens, CEO
eintellego Pty Ltd - The Networking Specialists
ske...@eintellego.net / www.eintellego.net
Phone: 1300 753 383, Fax: (+612) 8572 9954
Cell +61 (0)414 753 383 / skype://skeeve
www.linkedin.com/in/skeeve ; facebook.com/eintellego
--
eintellego - The Experts that the Experts call
- Juniper - HP Networking - Cisco - Arista -


> -Original Message-
> From: Karl Auer [mailto:ka...@biplane.com.au]
> Sent: Friday, 22 October 2010 10:00 AM
> To: nanog@nanog.org
> Subject: Re: IPv6 fc00::/7 - Unique local addresses
> 
> On Thu, 2010-10-21 at 01:46 -0700, Owen DeLong wrote:
> > > 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.
> 
> Fairly trivial amounts for most commercial entities, but prohibitive for
> all but the most enthusiastic home user.
> 
> Regards, K.
> 
> --
> ~~~
> Karl Auer (ka...@biplane.com.au)   +61-2-64957160 (h)
> http://www.biplane.com.au/kauer/   +61-428-957160 (mob)
> 
> GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
> Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF
> 1

Re: IPv6 fc00::/7 - Unique local addresses

[Jack Bates]

 On 10/21/2010 5:56 PM, George Bonser wrote:


How does your application on the host decide which address to use when
sourcing an outbound connection if you have two different subnets that
are globally routable?

Many systems generally will go with the closest source address bitwise 
to the destination address. Not perfect, but works. This assumes that 
the source addresses are equal on other metrics.


Jack

Re: IPv6 fc00::/7 — Unique local addresses

[Karl Auer]

On Thu, 2010-10-21 at 01:46 -0700, Owen DeLong wrote:
> > 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.

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

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)   +61-2-64957160 (h)
http://www.biplane.com.au/kauer/   +61-428-957160 (mob)

GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF
1


signature.asc
Description: This is a digitally signed message part

RE: Re: IPv6 fc00::/7 - Unique local addresses

[George Bonser]

> Sent: Thursday, October 21, 2010 3:16 PM
> To: Owen DeLong
> Cc: NANOG list
> Subject: Re: Re: IPv6 fc00::/7 - Unique local addresses
> 
> IPv4 think.
> 
> You don't re-address you add a new address to every node.  IPv6 is
> designed for multiple addresses.
> 

How does your application on the host decide which address to use when
sourcing an outbound connection if you have two different subnets that
are globally routable?

Re: Re: IPv6 fc00::/7 — Unique local addresses

[Mark Andrews]

In message <859028c2-9ed9-43ff-aaf9-6e2574048...@delong.com>, Owen DeLong write
s:
> 
> On Oct 20, 2010, at 10:28 PM, Mark Andrews wrote:
> 
> >=20
> > In message <4cbfc1d0.60...@apolix.co.za>, Graham Beneke writes:
> >> On 21/10/2010 02:41, Owen DeLong wrote:
> >>> On Oct 20, 2010, at 5:21 PM, Jeroen van Aart wrote:
>  Someone advised me to use GUA instead of ULA. But since for my =
> purposes th
> >> is is used for an IPv6 LAN would ULA not be the better choice?
> =20
> >>> IMHO, no. There's no disadvantage to using GUA and I personally =
> don't think
> >> ULA really serves a purpose. If you want to later connect this
> >>> LAN to the internet or something that connects to something that =
> connects t
> >> o something that connects to the internet or whatever, GUA provides
> >>> the following advantages:
> >>>   +   Guaranteed uniqueness (not just statistically probable =
> uniquene
> >> ss)
> >>>   +   You can route it if you later desire to
> >>>=20
> >>> Since ULA offers no real advantages, I don't really see the point.
> >>=20
> >> Someone insisted to me yesterday the RFC1918-like address space was =
> the=20
> >> only way to provide a 'friendly' place for people to start their =
> journey=20
> >> in playing with IPv6. I think that the idea of real routable IPs on a=20=
> 
> >> lab network daunts many people.
> >>=20
> >> I've been down the road with ULA a few years back and I have to agree=20=
> 
> >> with Owen - rather just do it on GUA.
> >=20
> > Your throwing the baby out with the bath water here.
> >=20
> > ULA, by itself, is a painful especially when you have global IPv4
> > reachability as you end up with lots of timeouts.  This is similar
> > to have a bad 6to4 upsteam link.  Just don't go there.
> >=20
> > ULA + PA works and provides stable internal addresses when your
> > upstream link in down the same way as RFC 1918 provides stable
> > internal addressing for IPv4 when your upstream link is down.
> >=20
> 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.

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.

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

> One over which you have little or no control unless you are running
> a 6to4 gateway of your own and can guarantee that nobody pretends
> to be one that is topologically closer to any of your users.
>
> >> I was adding IPv6 to a fairly large experimental network and started=20=
>
> >> using ULA. The local NREN then invited me to peer with them but I=20
> >> couldn't announce my ULA to them. They are running a 'public =
> Internet'=20
> >> network and have a backbone that will just filter them. 
> >>=20
> >> I think that the biggest thing that trips people up is that they =
> think=20
> >> that they'll just fix-it-with-NAT to get onto the GUA Internet. =
> Getting=20
> >> your own GUA from an RIR isn't tough - rather just do it. 
> >=20
> > 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. 
> >=20
> home network: 2620:0:930::/48
>
> Try again. 

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

> > Owen
--
Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

Re: Re: IPv6 fc00::/7 — Unique local addresses

[Mark Andrews]

In message , Owen DeLong write
s:
> >>> 
> >> Which is part one of the three things that have to happen to make ULA
> >> really bad for the internet.
> >> 
> >> 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.
> >> 
> > 
> > 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.
> > 
> _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.
> 
> 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.

IPv4 think.

You don't re-address you add a new address to every node.  IPv6 is
designed for multiple addresses.

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

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.

> when
> people do bad stuff with it, it will work and since it works, they won't
> go read the documentation explaining that what works is a bad
> idea.
> 
> >> Part 3 will be when that same provider (or some other provider in the
> >> same boat) takes the next step and starts trading routes of ULA space
> >> with other provider(s).
> >> 
> >> At that point, ULA = GUA without policy = very bad thing (tm).
> >> 
> >> Since feature creep of this form is kind of a given in internet history,
> >> I have no reason to believe it won't happen eventually with ULA.
> >> 
> > 
> > So I'm not sure I can see much benefit would be of paying a
> > huge amount of money to have ULA address space put in only a
> > limited part/domain of the global route table. The only way to
> > have ULA = GUA is to pay everybody on the Internet to carry it, and
> > that is assuming that everybody would be willing to accept the money
> > in the first place. That'd be far more expensive than just using GUA
> > addresses for global reachability.
> > 
> 
> No... The way it will work is that use of ULA as pseudo-GUA will
> spread slowly like cancer through the network.
> 
> When provider A and provider B both have customers throwing lots
> of money at them to route their ULA, provider A and provider B will
> swallow hard and agree to exchange those routes in both directions.
> 
> I wish I had your confidence in people doing the right thing, but,
> there are enough examples of RFC-1918 space in the GRT that
> I simply can't share your belief that it won't happen with ULA
> which doesn't have the reliability problems that RFC-1918 had.
> 
> Owen
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: IPv6 fc00::/7 — Unique local addresses

[Ray Soucy]

And since someone asked me for it off-list, example PACL for IOS to
filter RAs and DHCPv6 server traffic on incoming ports:

On each switch:

ipv6 access-list RA_Guard
 deny icmp any any router-advertisement
 deny udp any eq 547 any eq 546
 permit any any
end

And on each switchport:

ipv6 traffic-filter RA_Guard in

Your mileage may vary.  This was written for Catalyst 3560s and 3750s.
 Obviously you wouldn't apply it on the port your uplink is on.

On Thu, Oct 21, 2010 at 4:08 PM, Ray Soucy  wrote:
> Also,
>
> Keep in mind that DHCPv6 uses a DUID for host identification and not a
> MAC address.
>
> Here is an example ISC DHCPd configuration for an IPv6 network without
> open pool allocation (it will only respond for hosts in the config).
>
> # subnet6 for each network
> subnet6 FD00:1234:5678:9ABC::/64 { option dhcp6.name-servers
> FD00:1234:5678:9ABC::2, FD00:1234:5678:9ABC::3; }
>
> # host for each host
> host soucy-desktop.domain.net { host-identifier option dhcp6.client-id
> 00:01:00:01:11:ee:71:12:00:1a:a0:da:ba:7f; fixed-address6
> FD00:1234:5678:9ABC::A; }
>
> I believe the new version of ISC DHCPd has added code to be able to
> determine the MAC address instead of using a DUID, but I haven't
> tested it personally.
>
> On Thu, Oct 21, 2010 at 3:59 PM, Ray Soucy  wrote:
>> I think you're misunderstanding how DHCPv6 works.  Don't think of it
>> like DHCP that you're used to.
>>
>> DHCPv6 requires an IPv6 router advertisement to work.  There are three
>> flags of interest in a router advertisement.
>>
>> One of them is the "A" (autonomous) flag which is enabled by default
>> in almost every implementation I've seen.  This is what signals a host
>> that it is permitted to use stateless configuration with the prefix.
>>
>> There are also "M" (managed) and "O" other flags.  The "M" flag being
>> set signals the host that it should start a DHCPv6 client and make a
>> request for an address, the "O" flag signals that the host should ask
>> for "other" or additional configuration information through DHCPv6
>> (e.g. DNS servers).
>>
>> None of the flags are exclusive, so you can enable DHCPv6 by setting
>> the M flag, but unless you disable the A flag, hosts will still use
>> stateless configuration (in addition to DHCPv6 and receive two
>> addresses)
>>
>> If you want a DHCPv6-only environment, you simply disable the A flag
>> on the router advertisement.  This will stop hosts from using
>> stateless with the advertised prefix.
>>
>> The default gateway for the network is learned through the router
>> advertisement, not through DHCPv6, which is why it doesn't exist in
>> DHCPv6.
>>
>> Example IOS configuration:
>>
>> interface Vlan123
>>  description Test IPv6 Network
>>  ipv6 address FD00:1234:5678:9ABC::1/64
>>  no ipv6 unreachables
>>  ipv6 nd prefix default 2592000 604800 no-autoconfig
>>  ipv6 nd managed-config-flag
>>  ipv6 nd other-config-flag
>>  ipv6 nd router-preference High
>>  no ipv6 redirects
>>  ipv6 verify unicast source reachable-via rx
>>  ipv6 eigrp 123
>>  ipv6 dhcp relay destination FD00:1234:5678:9ABC::2
>>  ipv6 dhcp relay destination FD00:1234:5678:9ABC::3
>>
>> The "ipv6 nd prefix ... no-autoconfig" statement is what you're
>> looking for.  You need to type out timers to be able to get to it.
>> The values shown are just the Cisco defaults.
>>
>>
>>
>> On Thu, Oct 21, 2010 at 3:43 PM, Luca Tosolini  wrote:
>>> On Thu, 2010-10-21 at 14:19 -0400, Ray Soucy wrote:
>>>
 We've decided to disable SLAAC (State-Less Address Auto-Configuration)
 on almost all our IPv6 networks and use DHCPv6 exclusively.  This
 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.

>>>
>>> Ray,
>>> how do you convey the default-router information with DHCPv6 only. AFAIK
>>> there is no such field in DHCPv6...
>>>
>>> Luca.
>>>
>>>
>>
>>
>>
>> --
>> Ray Soucy
>>
>> Epic Communications Specialist
>>
>> Phone: +1 (207) 561-3526
>>
>> Networkmaine, a Unit of the University of Maine System
>> http://www.networkmaine.net/
>>
>
>
>
> --
> Ray Soucy
>
> Epic Communications Specialist
>
> Phone: +1 (207) 561-3526
>
> Networkmaine, a Unit of the University of Maine System
> http://www.networkmaine.net/
>



-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/

Re: IPv6 fc00::/7 — Unique local addresses

[Ray Soucy]

Also,

Keep in mind that DHCPv6 uses a DUID for host identification and not a
MAC address.

Here is an example ISC DHCPd configuration for an IPv6 network without
open pool allocation (it will only respond for hosts in the config).

# subnet6 for each network
subnet6 FD00:1234:5678:9ABC::/64 { option dhcp6.name-servers
FD00:1234:5678:9ABC::2, FD00:1234:5678:9ABC::3; }

# host for each host
host soucy-desktop.domain.net { host-identifier option dhcp6.client-id
00:01:00:01:11:ee:71:12:00:1a:a0:da:ba:7f; fixed-address6
FD00:1234:5678:9ABC::A; }

I believe the new version of ISC DHCPd has added code to be able to
determine the MAC address instead of using a DUID, but I haven't
tested it personally.

On Thu, Oct 21, 2010 at 3:59 PM, Ray Soucy  wrote:
> I think you're misunderstanding how DHCPv6 works.  Don't think of it
> like DHCP that you're used to.
>
> DHCPv6 requires an IPv6 router advertisement to work.  There are three
> flags of interest in a router advertisement.
>
> One of them is the "A" (autonomous) flag which is enabled by default
> in almost every implementation I've seen.  This is what signals a host
> that it is permitted to use stateless configuration with the prefix.
>
> There are also "M" (managed) and "O" other flags.  The "M" flag being
> set signals the host that it should start a DHCPv6 client and make a
> request for an address, the "O" flag signals that the host should ask
> for "other" or additional configuration information through DHCPv6
> (e.g. DNS servers).
>
> None of the flags are exclusive, so you can enable DHCPv6 by setting
> the M flag, but unless you disable the A flag, hosts will still use
> stateless configuration (in addition to DHCPv6 and receive two
> addresses)
>
> If you want a DHCPv6-only environment, you simply disable the A flag
> on the router advertisement.  This will stop hosts from using
> stateless with the advertised prefix.
>
> The default gateway for the network is learned through the router
> advertisement, not through DHCPv6, which is why it doesn't exist in
> DHCPv6.
>
> Example IOS configuration:
>
> interface Vlan123
>  description Test IPv6 Network
>  ipv6 address FD00:1234:5678:9ABC::1/64
>  no ipv6 unreachables
>  ipv6 nd prefix default 2592000 604800 no-autoconfig
>  ipv6 nd managed-config-flag
>  ipv6 nd other-config-flag
>  ipv6 nd router-preference High
>  no ipv6 redirects
>  ipv6 verify unicast source reachable-via rx
>  ipv6 eigrp 123
>  ipv6 dhcp relay destination FD00:1234:5678:9ABC::2
>  ipv6 dhcp relay destination FD00:1234:5678:9ABC::3
>
> The "ipv6 nd prefix ... no-autoconfig" statement is what you're
> looking for.  You need to type out timers to be able to get to it.
> The values shown are just the Cisco defaults.
>
>
>
> On Thu, Oct 21, 2010 at 3:43 PM, Luca Tosolini  wrote:
>> On Thu, 2010-10-21 at 14:19 -0400, Ray Soucy wrote:
>>
>>> We've decided to disable SLAAC (State-Less Address Auto-Configuration)
>>> on almost all our IPv6 networks and use DHCPv6 exclusively.  This
>>> 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.
>>>
>>
>> Ray,
>> how do you convey the default-router information with DHCPv6 only. AFAIK
>> there is no such field in DHCPv6...
>>
>> Luca.
>>
>>
>
>
>
> --
> Ray Soucy
>
> Epic Communications Specialist
>
> Phone: +1 (207) 561-3526
>
> Networkmaine, a Unit of the University of Maine System
> http://www.networkmaine.net/
>



-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/

Re: IPv6 fc00::/7 — Unique local addresses

[Ray Soucy]

I think you're misunderstanding how DHCPv6 works.  Don't think of it
like DHCP that you're used to.

DHCPv6 requires an IPv6 router advertisement to work.  There are three
flags of interest in a router advertisement.

One of them is the "A" (autonomous) flag which is enabled by default
in almost every implementation I've seen.  This is what signals a host
that it is permitted to use stateless configuration with the prefix.

There are also "M" (managed) and "O" other flags.  The "M" flag being
set signals the host that it should start a DHCPv6 client and make a
request for an address, the "O" flag signals that the host should ask
for "other" or additional configuration information through DHCPv6
(e.g. DNS servers).

None of the flags are exclusive, so you can enable DHCPv6 by setting
the M flag, but unless you disable the A flag, hosts will still use
stateless configuration (in addition to DHCPv6 and receive two
addresses)

If you want a DHCPv6-only environment, you simply disable the A flag
on the router advertisement.  This will stop hosts from using
stateless with the advertised prefix.

The default gateway for the network is learned through the router
advertisement, not through DHCPv6, which is why it doesn't exist in
DHCPv6.

Example IOS configuration:

interface Vlan123
 description Test IPv6 Network
 ipv6 address FD00:1234:5678:9ABC::1/64
 no ipv6 unreachables
 ipv6 nd prefix default 2592000 604800 no-autoconfig
 ipv6 nd managed-config-flag
 ipv6 nd other-config-flag
 ipv6 nd router-preference High
 no ipv6 redirects
 ipv6 verify unicast source reachable-via rx
 ipv6 eigrp 123
 ipv6 dhcp relay destination FD00:1234:5678:9ABC::2
 ipv6 dhcp relay destination FD00:1234:5678:9ABC::3

The "ipv6 nd prefix ... no-autoconfig" statement is what you're
looking for.  You need to type out timers to be able to get to it.
The values shown are just the Cisco defaults.



On Thu, Oct 21, 2010 at 3:43 PM, Luca Tosolini  wrote:
> On Thu, 2010-10-21 at 14:19 -0400, Ray Soucy wrote:
>
>> We've decided to disable SLAAC (State-Less Address Auto-Configuration)
>> on almost all our IPv6 networks and use DHCPv6 exclusively.  This
>> 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.
>>
>
> Ray,
> how do you convey the default-router information with DHCPv6 only. AFAIK
> there is no such field in DHCPv6...
>
> Luca.
>
>



-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/

Re: IPv6 fc00::/7 — Unique local addresses

[Luca Tosolini]

On Thu, 2010-10-21 at 14:19 -0400, Ray Soucy wrote:

> We've decided to disable SLAAC (State-Less Address Auto-Configuration)
> on almost all our IPv6 networks and use DHCPv6 exclusively.  This
> 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.
> 

Ray,
how do you convey the default-router information with DHCPv6 only. AFAIK
there is no such field in DHCPv6...

Luca.

RE: IPv6 fc00::/7 - Unique local addresses

[George Bonser]

> From: Ray Soucy 
> Sent: Thursday, October 21, 2010 5:49 AM
> To: Owen DeLong
> Cc: NANOG list
> Subject: Re: IPv6 fc00::/7 - Unique local addresses
> 
> See... You're falling into the same elitist mindset that I was trapped
> in a year ago.
> 
> Perception is a powerful thing.  And Joe IT guy at Mom and Pop dot com
> (who's network experience involves setting up a Linksys at home) loves
> his magical NAT box firewall appliance.  Over the last year I've been
> trying to fight the NAT war and have gotten pretty beat down.  It
> doesn't matter if *we* know NAT is wrong, undesirable, and breaks the
> Internet... we all live in the large scale, multi-homed, BGP, mega
> Internet land.

And BetaMAX was a much better format than VHS, too, from a technical
standpoint. It doesn't matter which is "better", it matters what people
want.  Telling people they can't have what they want leads to someone
somewhere providing them with what they want and making a fortune on it.

> Start working with smaller shops, and you'll find the typical setup is
> a bunch of switches and a "VPN Firewall" picked up from Best Buy, or
> maybe a Sonicwall or something.  These guys couldn't manage public
> IPv4 let alone public IPv6, because the term "private" gives them that
> warm and fuzzy false sense of security and lets them change their ISP
> without reconfiguring a single thing (they often wouldn't know where
> to start anyway).

I am not sure there really is a such thing as a "secure" network.  If
you can somehow get a host inside a network to send the first packet to
you, you are in.  Yeah, all those filters and NATs prevent you from
being able to send the first packet, but as long as people are dragging
in laptops, thumb drives, opening email attachments, and browsing the
web, there is no such thing as a "secure" network if it has internet
access.  Even the deepest packet inspection won't make you secure of the
traffic going back and forth abides by the protocol rules.  Is that
really a file upload and download going on, or is it a bi-directional
tunnel disguised as file transfers that never end and is someone now
doing a complete scan of your network from one of your employee's
workstations?

Having a lock on the door is fine, but for a door to be useful, you must
be able to open it from the inside. And when you take a delivery, are
you sure what is in that box is what is really on the packing slip? And
if you take it out of the box and look on it, is it still *really* what
it says on the packing slip?  Sort of like a birthday cake arriving at a
prison.

> They *will* fight you, and tell you to your face that if you want to
> take NAT away from them it will be from their cold dead hands.

And it isn't NAT in and of itself that is attractive.  Those people
aren't talking about static NAT where you are just translating the
network prefix.  They are talking dynamic port-based PAT so that the
translation doesn't exist until the first packet goes in the outbound
direction.  Like it or not, that DOES provide some barrier of entry to
someone outside wishing to initiate a connection from the outside.  You
cannot predict in advance what outside address/port will be associated
with which inside address/port or if any such association even exists
and a lot of people have already made up their minds that the breakage
that causes for various things is offset by the perceived benefit of
that barrier and worth the price of dealing with that breakage.

 
> Why? Because we've had 10 years of "consultants" selling NAT as the
> best thing for security since sliced bread.
> 
> Maybe we could get them to do it the right way if they had some sort
> of IPv6 appliance that dumbed things down, but it simply doesn't exist
> yet.  When it is created, it will be created by the people with the
> NAT mindset wishing to maintain the status quo.
> 
> At least that's my prediction...

I tend to agree with that.  Not saying that I think that is the best way
to go, mind you, just saying that I can see such a thing happening and
all the jumping up and down on NANOG isn't going to change that because
it is the end user that decides in the end what gets built and what
doesn't.  So either put into the protocol a specific prohibition of NAT,
engineer the protocol so NAT can't possibly work, or get ready to accept
that you are going to be dealing with it.

> We need to keep in mind that most on this list is likely at a
> completely different level than anything you'd find in the SMB
> community.

I have tried making that point privately to many individuals but it
doesn't seem to click and is taken as if I am "defending" or somehow
rationalizing that "dumbed down" behavio

Re: IPv6 fc00::/7 ??? Unique local addresses

[Steve Meuse]

Mark Smith expunged 
(na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org):

> ULAs should never and are prohibited from appearing in the global route table

The problem with this statement is that everyone thinks their own table isn't 
the "Global Routing Table." 

-Steve

RE: IPv6 fc00::/7 - Unique local addresses

[George Bonser]

> -Original Message-
> From: Owen DeLong [mailto:o...@delong.com]
> Sent: Thursday, October 21, 2010 5:26 AM
> To: Ray Soucy
> Cc: NANOG list
> 
> If you're using IPv4 with multiple providers giving you different NAT
> pools, then, you're looking at outbound, not inbound resiliency and
> the DNS stuff you described is irrelevant. As long as your outbound
> gateway(s) have some way to detect provider down-ness (all the
> same tactics that work for IPv4 here work for IPv6 with pretty much
> the same flaws), you can do the same thing. The difference is that
> in IPv6, you have to tell the hosts which IPv6 source prefix to use.
> The easy way to do that is to alter the desired/valid lifetimes in
> your internal RAs accordingly. This isn't hard to script.

That doesn't really work because both of your providers may be "up" but
one of them is not reachable by the network at the other end.  You
cannot predict ahead of time which address a remote network will be able
to reach.  Being multihomed with one block of addresses solves that
problem in that as long as the distant end is getting routing
information originated by either of the upstreams, you are good.  Also,
announcing two network blocks for the same service is a bad idea.  If
one becomes unreachable while a transaction is in progress, you can't
fail over until the connection times out and it reconnects on the other
IP.  And of the application at the other end is some "secure" java
application, it might cache that unreachable IP forever until the
application is bounced or until its default cache TTL expires which
might be a different TTL than in the DNS information.


> If you're using IPv4 with BGP and advertising the same prefix(es)
> to multiple providers, the same thing works in IPv6 with nearly
> identical processes.

Yeah, that's the only way that really works.  

> 
> I don't see what NAT gives you for EITHER of those things.

Ok, say you have your machines multinetted with two GUA nets on the same
interface. Which IP does the application choose to source traffic from
when it originates an outbound connection to the world?  You can't
predict which one is "broken" somewhere along the path.  Load balancing
inbound is a much simpler model than load balancing outbound and unless
you want to push your entire BGP table down to the host, well, it just
doesn't work.

What *does* work is having your internal net addressed in some stable
way that doesn't change when your upstream changes and in IPv4 you
simply change your NAT pools to reflect the change. Done, your entire
network is "renumbered" as far as the Internet is concerned.  If your
hosts are numbered in PA space, changing providers means potentially
touching the configurations of all machines.  A network provider will
love that because it discourages customers from changing providers and
makes the customer stickier to them. A customer might not feel so
comfortable about that and want more independence of the provider's
network.


 

Re: IPv6 fc00::/7 — Unique local addresses

[Ray Soucy]

One thing to keep in mind is that your IPv6 router and IP router can
be completely different devices.  There is no need to forklift your
firewall or current setup if you can easily add an IPv6 router to the
network.

Using multiple ISPs is still something that is a bit tricky.  A lot of
people have gotten used to the Dual-WAN Firewall appliance boxes that
accept connections from two ISPs and handle the failover, depending on
NAT to maintain the functionality of the Internal network.

Larger organizations can arrange to have IPv6 transit and announce a
single prefix over BGP.  Most providers won't want to see this setup
for an SMB so they're out of luck.

One thing that has changed, though, is Metro Ethernet offerings have
gotten a lot better.  I would say the most painless way to go would be
to use one ISP for L3, and two ME providers to give diverse L2 paths
to that L3 ISP.  It means dealing with more companies, and moving
failover to L2, but it's pretty rare that the cause of a connection
problem is at the ISP these days (it's more often a bad connection
between you and the ISP), so just having redundancy at L2 might be
enough.

Sadly, that model doesn't really exist in the US right now, and it
might take quite a bit of work convincing providers to coordinate to
make it all work.

The other option, which was the intent of IPv6 when being designed
(but that was 10 years ago or so) was that every PC would have a
separate address from each ISP.  In this situation you could depend on
ULA (local addressing) for access to all internal services so that if
one of the global prefixes goes away it doesn't impact internal
operation, but it does require a device to kind of coordinate that-
such a device doesn't exist yet, and there are some issues with
getting PCs to handle address selection correctly.  I suspect if this
does happen (and it could, it's not a horrible model) it will take a
few more years before it's "easy".  It's too bad they axed the site
local scope for this kind of environment.

For now, I would recommend just going with a single IPv6 provider
since I have yet to encounter IPv6-only content that is mission
critical.  That will at least give you access to the IPv6 internet
now, but give the IPv6 market time to come around to meet the needs of
SMB and wanting redundancy in IPv6 access.

I'm not aware of any appliance that does a good job at IPv6, yet...

If it were me I would build up a Linux box as a IPv6 firewall, router,
etc.  It's really too bad that there isn't such an appliance yet.  You
could just use a Cisco ISR (like an 1841) as your IPv6 on a stick
router, but the problem is that you really want to keep in mind that
once you give out global addresses to hosts they're not behind your
NAT firewall for IPv6.  So you'll want to implement some sort of
stateful firewall for IPv6, or enable host-based IPv6 firewalls.

We've decided to disable SLAAC (State-Less Address Auto-Configuration)
on almost all our IPv6 networks and use DHCPv6 exclusively.  This
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.

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.

It works rather well.

On Thu, Oct 21, 2010 at 12:29 PM, Allen Smith  wrote:
> Hi All,
>
> I've inherited a small network with a couple of Internet connections through
> different providers, I'll call them Slow and Fast.
>
> We use RFC 1918 space internally and have a pair of external firewalls that
> handle NAT and such.
>
> Due to internal policy (read money), some users default to the Slow
> connection and some default to Fast. Using probes and policy routing, a
> failure of one of the ISPs is generally transparent, outside of the usual
> session resets for things like ssh or remote control sessions).
>
> Looking forward to the next 12 months, we may have clients that are living
> in IPv6 space. Our ISPs are happy to give us IPv6 allocations and our
> network gear vendors either have GA IPv6 code now or will soon.
>
> We have been somewhat spoiled by our firewall/NAT boxes, the stuff just
> works for our needs and the combination of NAT and policy routing keeps
> people on the circuits they are paying for. Am trying to decide how I would
> implement this kind of policy in the new world of globally
> trackable^H^H^H^H^H^H^H routable IPs for my desktops. Solutions seem to be:
>
> 1) Purchase some BGP capable routers, grab PI space. Here I can obv choose
> outbou

Re: IPv6 fc00::/7 — Unique local addresses

[Ben Jencks]

On Thu, Oct 21, 2010 at 04:46, Owen DeLong  wrote:
>
> On Oct 20, 2010, at 10:28 PM, Mark Andrews wrote:
>> 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
>
> Try again.

How do you justify that to ARIN? My reading of the NRPM 6.5.8
("qualify for an IPv4 assignment or allocation from ARIN under the
IPv4 policy currently in effect") and 4.3 (v4 /24 minimum for
multihoming, 50% utilization) is that you need at least 128 devices to
get a multihoming allocation. That's quite a home network you have.

In a related vein, I'm looking at IPv6-numbering a non-connected
private network of a few hundred hosts, and while a GUA assignment
would be ideal, it looks like I need at least 2048 (50% of a v4 /20)
devices to qualify for a non-multihomed v6 assignment. Am I missing
something?

-Ben

RE: IPv6 fc00::/7 - Unique local addresses

[George Bonser]

> -Original Message-
> From: Ray Soucy > Sent: Thursday, October 21, 2010 5:00 AM
> To: Jeroen van Aart
> Cc: NANOG list
> Subject: Re: IPv6 fc00::/7 - Unique local addresses


> The mindset of using RFC1918 space, throwing everything behind a NAT
> box, and not having to re-configure systems when you change ISP
> doesn't exist in IPv6.  There is no IPv6 NAT (yet).

And that is one of the real challenges here.  An office that is not
multihomed and has only a short commit to a provider may be reluctant to
number their network in that provider's PA space if they really do not
want to remain "sticky" to that provider.  I can understand that
position as I tend not to want to be "sticky" to a provider either.
Things change quickly in the world and market rates for connectivity can
change rapidly. Short term agreements that give the user the flexibility
to move easily to a different provider can be desirable but it might
also be impossible to convince the CFO that they need to obtain two
providers in order to get their own address block.

The issue driving many small networks to multihome isn't really so much
that they NEED to multihome, it is because they really want to be able
to change providers without renumbering their network/services.
RFC-1918 with NAT gave them that flexibility with v4.  LUA doesn't
really give them that as it currently stands.  You can number your
networks with both, but that can lead to some interesting RA
configurations and can be fun to watch depending on what gear is in
place.

> 
> If you wanted to setup an "island" of IPv6 that would never talk to
> the Internet, then you could use ULA, but that would only be needed if
> you plan on routing between LANs.  Remember that by default every IPv6
> host has a link-local address allowing it to talk to any directly
> connected hosts without configuration.  So if you're simply looking
> for some sort of ad-hoc network, it's likely already there.

The problem is in putting such link local addresses into the local DNS
so hosts can find each other.  I generally consider link local IPs in
DNS to be a "bad idea" unless it is in a subdomain dedicated that that
specific subnet. Given a flat network that isn't routed and is used for
clustering machines together, it is a "flat" layer 2 net with no layer3
interfaces except for the hosts themselves (no router interfaces on the
network) then having a subdomain just for the hosts on that specific
subnet that include the link local IPs on that specific subnet might
work.  But that is the right application of ULA.  That subnet will never
get routed off the site so what the heck.  In fact, it will never get
routed at all.


> As much as I hate NAT and want to see it go away.  I think the biggest
> transition mechanism for people to get online with IPv6 will be some
> sort of appliance that does NAT of global IPv6 addresses to private
> IPv4 addresses to keep all the people living in the NAT world from
> having to redesign their networks.  It's ugly, but its the path of
> least resistance and that's likely what will happen when we see IPv6
> become required to do business... at least as a stepping stone.

That is going to be a tough sell to the network operators. The
enterprise guys are all going to say "we need stable addressing that is
not tied to a provider" the network operators are going to say
"multihome and get your own block" and the enterprise guys are going to
say "we already have two connections to our primary provider and can
tolerate an outage, this isn't a business killing critical network and
it would take a major failure of our current provider or the TELCO to
cause us to be completely unreachable, we can't make the business case
to justify two transit provider contracts but we DO need stable address
space because there are just so many problems with autoconfiguration
that we can't make that work in a reliable way".

And maybe fixing autoconfiguration is where the key lies to this
problem.  Having RA announce multiple prefixes is a challenge, though,
and as far as I know there is no standard way of saying: "get all
available prefixes from the router and use that prefix to mask this host
address".  For example, say I have configured the host with a "static
host mask", for lack of a better name, that uses a ULA address as the
mask.  Say the mask is fdf7:77d7:b935:123:1b

The router is announcing  fd11:d148:570f::/64 (a ULA subnet), and
2001:200:c000:f473::/64 (some random thing I pulled out of BGP plus some
randomness representing some assigned space).

So I overlay those prefixes onto the "default" host IP mask.  I end up
configuring fd11:d148:570f::123:1b/64 2001:200:c000:f473:123:1b/64.
As I am applying a unique local mask to either a u

Re: IPv6 fc00::/7 — Unique local addresses

[William Herrin]

On Wed, Oct 20, 2010 at 9:49 PM, Matthew Kaufman  wrote:
> On 10/20/2010 5:51 PM, Owen DeLong wrote:
>> 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.
>
> Is this happening now with RFC 1918 addresses and IPv4?

Some designs for the "carrier NATs" that are supposed to tide us over
from from v4 depletion through v6 deployment would seem to be an open
door for this scenario.


>> Part 3 will be when that same provider (or some other provider in the
>> same boat) takes the next step and starts trading routes of ULA space
>> with other provider(s).
>
> Is this happening now with RFC 1918 addresses and IPv4?

No. There's too much complexity associated with multiple ISPs
negotiating private routing policies while VPNs work very well without
needing special services from the ISP.

Owen has this notion that there's a natural evolutionary path that
will bring about some circumstance where two particular ISPs find it
advantageous to swap ULA routes. That same driving force would
presumably lead those ISPs to interact with a third and so on until
the use of ULA addresses on the public Internet was a defacto
standard.

If there's a credible scenario where two ISPs and the folks paying
them would find such a course of action preferable to the myriad other
options for solving the given problem, I haven't heard it yet. If such
a scenario exists, it's not obvious.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: IPv6 fc00::/7 — Unique local addresses

[Allen Smith]

Hi All,

I've inherited a small network with a couple of Internet connections through
different providers, I'll call them Slow and Fast.

We use RFC 1918 space internally and have a pair of external firewalls that
handle NAT and such.

Due to internal policy (read money), some users default to the Slow
connection and some default to Fast. Using probes and policy routing, a
failure of one of the ISPs is generally transparent, outside of the usual
session resets for things like ssh or remote control sessions).

Looking forward to the next 12 months, we may have clients that are living
in IPv6 space. Our ISPs are happy to give us IPv6 allocations and our
network gear vendors either have GA IPv6 code now or will soon.

We have been somewhat spoiled by our firewall/NAT boxes, the stuff just
works for our needs and the combination of NAT and policy routing keeps
people on the circuits they are paying for. Am trying to decide how I would
implement this kind of policy in the new world of globally
trackable^H^H^H^H^H^H^H routable IPs for my desktops. Solutions seem to be:

1) Purchase some BGP capable routers, grab PI space. Here I can obv choose
outbound path, but we are typical in that our inbound to outbound is 6 or 7
to 1.

2) Assign PA space from the ISPs to the appropriate devices. What do I do
when I loose a provider?

3) Make loud noises to my firewall vendor to include equivalent NAT/ISP
failover functionality (even 6to6 NAT would be fine).

Anyway, another sample of 1, but I do work for a managed services provider
and see many small orgs facing similary choices. I personally am happy to
use globally routable addresses and will work through the privacy and
perceived security implications of NAT/nonat, I just want the same ease of
use and flexibility I have today in a SMB environment.

Cheers,
-Allen

Re: IPv6 fc00::/7 — Unique local addresses

[Ray Soucy]

See... You're falling into the same elitist mindset that I was trapped
in a year ago.

Perception is a powerful thing.  And Joe IT guy at Mom and Pop dot com
(who's network experience involves setting up a Linksys at home) loves
his magical NAT box firewall appliance.  Over the last year I've been
trying to fight the NAT war and have gotten pretty beat down.  It
doesn't matter if *we* know NAT is wrong, undesirable, and breaks the
Internet... we all live in the large scale, multi-homed, BGP, mega
Internet land.

Start working with smaller shops, and you'll find the typical setup is
a bunch of switches and a "VPN Firewall" picked up from Best Buy, or
maybe a Sonicwall or something.  These guys couldn't manage public
IPv4 let alone public IPv6, because the term "private" gives them that
warm and fuzzy false sense of security and lets them change their ISP
without reconfiguring a single thing (they often wouldn't know where
to start anyway).

They *will* fight you, and tell you to your face that if you want to
take NAT away from them it will be from their cold dead hands.

Why? Because we've had 10 years of "consultants" selling NAT as the
best thing for security since sliced bread.

Maybe we could get them to do it the right way if they had some sort
of IPv6 appliance that dumbed things down, but it simply doesn't exist
yet.  When it is created, it will be created by the people with the
NAT mindset wishing to maintain the status quo.

At least that's my prediction...

We need to keep in mind that most on this list is likely at a
completely different level than anything you'd find in the SMB
community.  They can't afford to hire "networking" people, they hire
"IT" people who are tasked with anything related to technology and
usually completely understaffed.  Thus they want the quick, painless,
easy solution.

On Thu, Oct 21, 2010 at 8:26 AM, Owen DeLong  wrote:
>
> On Oct 21, 2010, at 4:59 AM, Ray Soucy wrote:
>
>> Sorry for the double post.  From re-reading the thread it doesn't
>> sound like you might want ULA at all.
>>
>> The mindset of using RFC1918 space, throwing everything behind a NAT
>> box, and not having to re-configure systems when you change ISP
>> doesn't exist in IPv6.  There is no IPv6 NAT (yet).
>>
> And hopefully there never will be...
>
>> If you wanted to setup an "island" of IPv6 that would never talk to
>> the Internet, then you could use ULA, but that would only be needed if
>> you plan on routing between LANs.  Remember that by default every IPv6
>> host has a link-local address allowing it to talk to any directly
>> connected hosts without configuration.  So if you're simply looking
>> for some sort of ad-hoc network, it's likely already there.
>>
> You may want non-LL space even if you aren't routing, since for LL,
> the destination address has to include the outbound interface name
> or it doesn't work.
>
>> As much as I hate NAT and want to see it go away.  I think the biggest
>> transition mechanism for people to get online with IPv6 will be some
>> sort of appliance that does NAT of global IPv6 addresses to private
>> IPv4 addresses to keep all the people living in the NAT world from
>> having to redesign their networks.  It's ugly, but its the path of
>> least resistance and that's likely what will happen when we see IPv6
>> become required to do business... at least as a stepping stone.
>>
> NAT64 already exists, although generally not for that application.
>
> I'm not convinced it is the path of least resistance, technically. If
> you mean politically, then, yes, but, making engineering decisions
> based on the political path of least resistance tends to cause more
> damage than it resolves.
>
> You don't actually have to redesign your IPv4 NAT network to
> put IPv6 on it in parallel. You just need to recognize that the
> IPv6 stateful firewall now provides your IPv6 security without
> needing to mangle the packet header in the process. You should
> be able to put all the same exact policies in place, without the
> nasty address translation bits.
>
>> The idea to use multiple PA IPv6 allocations and have multiple GUAs
>> for each host wasn't a bad one.  It would certainly make the Internet
>
> If it worked, it would be a great one, but...
>
>> routing table a lot more stable to not have everyone touching BGP...
>> But they failed to fix DNS in a way that would make it possible.  We
>
> Not just DNS... It would have impacted TCP, to some extent, UDP,
> applications, etc.
>
>> already have priority for MX records.  If we had priority for all
>> records, and resolvers would remember when one was unreachable for a
>> short time, then yes, you could have www.yourdomain.com point to
>
> The resolver doesn't have any way to know the reachability status of
> a given address from the resolver client. The information simply isn't
> available to the resolver. I suppose you could design a mechanism for
> the client to send feedback to the resolver, but, that's pretty hokey.
>
>> multiple

Re: IPv6 fc00::/7 — Unique local addresses

[Owen DeLong]

On Oct 21, 2010, at 4:59 AM, Ray Soucy wrote:

> Sorry for the double post.  From re-reading the thread it doesn't
> sound like you might want ULA at all.
> 
> The mindset of using RFC1918 space, throwing everything behind a NAT
> box, and not having to re-configure systems when you change ISP
> doesn't exist in IPv6.  There is no IPv6 NAT (yet).
> 
And hopefully there never will be...

> If you wanted to setup an "island" of IPv6 that would never talk to
> the Internet, then you could use ULA, but that would only be needed if
> you plan on routing between LANs.  Remember that by default every IPv6
> host has a link-local address allowing it to talk to any directly
> connected hosts without configuration.  So if you're simply looking
> for some sort of ad-hoc network, it's likely already there.
> 
You may want non-LL space even if you aren't routing, since for LL,
the destination address has to include the outbound interface name
or it doesn't work.

> As much as I hate NAT and want to see it go away.  I think the biggest
> transition mechanism for people to get online with IPv6 will be some
> sort of appliance that does NAT of global IPv6 addresses to private
> IPv4 addresses to keep all the people living in the NAT world from
> having to redesign their networks.  It's ugly, but its the path of
> least resistance and that's likely what will happen when we see IPv6
> become required to do business... at least as a stepping stone.
> 
NAT64 already exists, although generally not for that application.

I'm not convinced it is the path of least resistance, technically. If
you mean politically, then, yes, but, making engineering decisions
based on the political path of least resistance tends to cause more
damage than it resolves.

You don't actually have to redesign your IPv4 NAT network to
put IPv6 on it in parallel. You just need to recognize that the
IPv6 stateful firewall now provides your IPv6 security without
needing to mangle the packet header in the process. You should
be able to put all the same exact policies in place, without the
nasty address translation bits.

> The idea to use multiple PA IPv6 allocations and have multiple GUAs
> for each host wasn't a bad one.  It would certainly make the Internet

If it worked, it would be a great one, but...

> routing table a lot more stable to not have everyone touching BGP...
> But they failed to fix DNS in a way that would make it possible.  We

Not just DNS... It would have impacted TCP, to some extent, UDP,
applications, etc.

> already have priority for MX records.  If we had priority for all
> records, and resolvers would remember when one was unreachable for a
> short time, then yes, you could have www.yourdomain.com point to

The resolver doesn't have any way to know the reachability status of
a given address from the resolver client. The information simply isn't
available to the resolver. I suppose you could design a mechanism for
the client to send feedback to the resolver, but, that's pretty hokey.

> multiple PA GUAs and if one was down users would nicely fail-over to
> the other.  Unfortunately, if you have a host record with multiple
> s and one of them is unreachable, it will just mean that for some
> users the request will time out (as its just doing a round-robin and
> not trying others when things don't respond).
> 
Actually, unless the client software is exceptionally poorly written, it
won't time out, but, the delay before trying the next host is exceedingly
long (30 seconds) if you don't get an unreachable message back about
the first attempt(s).

> In theory, you could try to get around the limitation by having a TTL
> of 30 seconds or something on your records, and have a system that
> would update DNS records when a connection dropped, but that's
> assuming people aren't deciding to set minimum cache times of their
> own.
> 
We already know that M$ absolutely breaks this across the board.

> I think the best model possible with existing technology that's
> available is to separate L2 and L3 and use provider redundancy at L2
> (multiple ME transport providers to your single, redundant, L3 transit
> provider).  If you need more redundancy that that, you're likely using
> BGP for IPv4 already, anyway.
> 
You can get exactly the same reliability from IPv6 as you have in IPv4
using pretty much exactly the same tactics.

If you're using IPv4 with multiple providers giving you different NAT
pools, then, you're looking at outbound, not inbound resiliency and
the DNS stuff you described is irrelevant. As long as your outbound
gateway(s) have some way to detect provider down-ness (all the
same tactics that work for IPv4 here work for IPv6 with pretty much
the same flaws), you can do the same thing. The difference is that
in IPv6, you have to tell the hosts which IPv6 source prefix to use.
The easy way to do that is to alter the desired/valid lifetimes in
your internal RAs accordingly. This isn't hard to script.

If you're using IPv4 with BG

Re: IPv6 fc00::/7 — Unique local addresses

[Ray Soucy]

I guess my point is that as soon as you introduced the human element
into ULA with no accountability, it became a lost cause.  People can't
be trusted to respect the RFC once they know it's non-routed address
space, and I suspect most won't.  Just like countless vendors still
use 1.1.1.1 as a baked-in management address even though there was
never a time when that was allowed.  It was a nice idea, but as soon
as you let people "choose" the "random" number, well... there you go.
At least if you stay within the FD space we have a chance at using FC
correctly.

On Thu, Oct 21, 2010 at 7:47 AM, Owen DeLong  wrote:
>
> On Oct 21, 2010, at 4:33 AM, Ray Soucy wrote:
>
>> For for all intents and purposes if you're looking for RFC1918 style
>> space in IPv6 you should consider the block FD00::/8 not FC00::/7 as
>> the FC00::/8 space is reserved in ULA for assignment by a central
>> authority (who knows why, but with that much address space nobody
>> really cares).
>>
>> People may throw a fit at this, but as far as I'm concerned FD00::/8
>> will never leave the edge of our network (we null route ULA space
>> before it can leak out, just like you would with RFC1918 space).  So
>> you can pretty much use it has you see fit.  If you want to keep your
>> ULA space short there is nothing stopping you from using something
>> like FD00::1 as a valid address.
>>
> I have no problem with that. My concern is that people will use FD00::/8
> space in OTHER ways, and, since it has potential uniqueness if you
> follow the RFC, it has greater potential for undesired success than
> RFC-1918.
>
>> You could embed your ASN into it or some other identifier if you want
>> to avoid conflicts with other non-routed address space which should
>> never enter or leave your network from the outside, but I'm just not
>> seeing the practical application for this.
>>
> That only avoids conflicts if everyone within the networks to which
> you may communicate uses the same system of uniqueness.
> Think beyond today to the future possibility of M&A of other companies
> also using ULA, etc.
>
> Owen
>
>> On Wed, Oct 20, 2010 at 5:48 PM, Jeroen van Aart  wrote:
>>> 
>>>
>>> According to http://en.wikipedia.org/wiki/IPv6_address#Special_addresses an
>>> fc00::/7 address includes a 40-bit pseudo random number:
>>>
>>> "fc00::/7 — Unique local addresses (ULA's) are intended for local
>>> communication. They are routable only within a set of cooperating sites
>>> (analogous to the private address ranges 10/8, 172.16/12, and 192.168/16 of
>>> IPv4).[12] The addresses include a 40-bit pseudorandom number in the routing
>>> prefix intended to minimize the risk of conflicts if sites merge or packets
>>> are misrouted into the Internet. Despite the restricted, local usage of
>>> these addresses, their address scope is global, i.e. they are expected to be
>>> globally unique."
>>>
>>> I am trying to set up a local IPv6 network and am curious why all the
>>> examples I come accross do not seem to use the 40-bit pseudorandom number?
>>> What should I do? Use something like fd00::1234, or incorporate something
>>> like the interface's MAC address into the address? It'd make the address
>>> quite unreadable though.
>>>
>>> Thanks,
>>> Jeroen
>>>
>>> --
>>> http://goldmark.org/jeff/stupid-disclaimers/
>>> http://linuxmafia.com/~rick/faq/plural-of-virus.html
>>>
>>>
>>
>>
>>
>> --
>> Ray Soucy
>>
>> Epic Communications Specialist
>>
>> Phone: +1 (207) 561-3526
>>
>> Networkmaine, a Unit of the University of Maine System
>> http://www.networkmaine.net/
>
>



-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/

Re: IPv6 fc00::/7 — Unique local addresses

[Ray Soucy]

Sorry for the double post.  From re-reading the thread it doesn't
sound like you might want ULA at all.

The mindset of using RFC1918 space, throwing everything behind a NAT
box, and not having to re-configure systems when you change ISP
doesn't exist in IPv6.  There is no IPv6 NAT (yet).

If you wanted to setup an "island" of IPv6 that would never talk to
the Internet, then you could use ULA, but that would only be needed if
you plan on routing between LANs.  Remember that by default every IPv6
host has a link-local address allowing it to talk to any directly
connected hosts without configuration.  So if you're simply looking
for some sort of ad-hoc network, it's likely already there.

As much as I hate NAT and want to see it go away.  I think the biggest
transition mechanism for people to get online with IPv6 will be some
sort of appliance that does NAT of global IPv6 addresses to private
IPv4 addresses to keep all the people living in the NAT world from
having to redesign their networks.  It's ugly, but its the path of
least resistance and that's likely what will happen when we see IPv6
become required to do business... at least as a stepping stone.

The idea to use multiple PA IPv6 allocations and have multiple GUAs
for each host wasn't a bad one.  It would certainly make the Internet
routing table a lot more stable to not have everyone touching BGP...
But they failed to fix DNS in a way that would make it possible.  We
already have priority for MX records.  If we had priority for all
records, and resolvers would remember when one was unreachable for a
short time, then yes, you could have www.yourdomain.com point to
multiple PA GUAs and if one was down users would nicely fail-over to
the other.  Unfortunately, if you have a host record with multiple
s and one of them is unreachable, it will just mean that for some
users the request will time out (as its just doing a round-robin and
not trying others when things don't respond).

In theory, you could try to get around the limitation by having a TTL
of 30 seconds or something on your records, and have a system that
would update DNS records when a connection dropped, but that's
assuming people aren't deciding to set minimum cache times of their
own.

I think the best model possible with existing technology that's
available is to separate L2 and L3 and use provider redundancy at L2
(multiple ME transport providers to your single, redundant, L3 transit
provider).  If you need more redundancy that that, you're likely using
BGP for IPv4 already, anyway.

The real problem never goes away, though.  People like the operational
control and simplicity that they get with NAT.  If the provider goes
down, they still work internally, if they have multiple providers, the
internal network doesn't care which is active, and if they need to
host services, they usually go with a hosting company off-site.  I
really don't think it will be long before we see some magic IPv6 NAT
boxes start to pop up, whether or not standards exist for them, and it
will be and ugly nightmare.

IPv6 is simple enough for larger networks (like universities and
governments) but very little attention has been giving to the SMB
community and their needs with IPv6.

On Thu, Oct 21, 2010 at 7:33 AM, Ray Soucy  wrote:
> For for all intents and purposes if you're looking for RFC1918 style
> space in IPv6 you should consider the block FD00::/8 not FC00::/7 as
> the FC00::/8 space is reserved in ULA for assignment by a central
> authority (who knows why, but with that much address space nobody
> really cares).
>
> People may throw a fit at this, but as far as I'm concerned FD00::/8
> will never leave the edge of our network (we null route ULA space
> before it can leak out, just like you would with RFC1918 space).  So
> you can pretty much use it has you see fit.  If you want to keep your
> ULA space short there is nothing stopping you from using something
> like FD00::1 as a valid address.
>
> You could embed your ASN into it or some other identifier if you want
> to avoid conflicts with other non-routed address space which should
> never enter or leave your network from the outside, but I'm just not
> seeing the practical application for this.
>
> On Wed, Oct 20, 2010 at 5:48 PM, Jeroen van Aart  wrote:
>> 
>>
>> According to http://en.wikipedia.org/wiki/IPv6_address#Special_addresses an
>> fc00::/7 address includes a 40-bit pseudo random number:
>>
>> "fc00::/7 — Unique local addresses (ULA's) are intended for local
>> communication. They are routable only within a set of cooperating sites
>> (analogous to the private address ranges 10/8, 172.16/12, and 192.168/16 of
>> IPv4).[12] The addresses include a 40-bit pseudorandom number in the routing
>> prefix intended to minimize the risk of conflicts if sites merge or packets
>> are misrouted into the Internet. Despite the restricted, local usage of
>> these addresses, their address scope is global, i.e. they are expected to be
>> globally unique."
>>
>

Re: IPv6 fc00::/7 — Unique local addresses

[Owen DeLong]

On Oct 21, 2010, at 4:33 AM, Ray Soucy wrote:

> For for all intents and purposes if you're looking for RFC1918 style
> space in IPv6 you should consider the block FD00::/8 not FC00::/7 as
> the FC00::/8 space is reserved in ULA for assignment by a central
> authority (who knows why, but with that much address space nobody
> really cares).
> 
> People may throw a fit at this, but as far as I'm concerned FD00::/8
> will never leave the edge of our network (we null route ULA space
> before it can leak out, just like you would with RFC1918 space).  So
> you can pretty much use it has you see fit.  If you want to keep your
> ULA space short there is nothing stopping you from using something
> like FD00::1 as a valid address.
> 
I have no problem with that. My concern is that people will use FD00::/8
space in OTHER ways, and, since it has potential uniqueness if you
follow the RFC, it has greater potential for undesired success than
RFC-1918.

> You could embed your ASN into it or some other identifier if you want
> to avoid conflicts with other non-routed address space which should
> never enter or leave your network from the outside, but I'm just not
> seeing the practical application for this.
> 
That only avoids conflicts if everyone within the networks to which
you may communicate uses the same system of uniqueness.
Think beyond today to the future possibility of M&A of other companies
also using ULA, etc.

Owen

> On Wed, Oct 20, 2010 at 5:48 PM, Jeroen van Aart  wrote:
>> 
>> 
>> According to http://en.wikipedia.org/wiki/IPv6_address#Special_addresses an
>> fc00::/7 address includes a 40-bit pseudo random number:
>> 
>> "fc00::/7 — Unique local addresses (ULA's) are intended for local
>> communication. They are routable only within a set of cooperating sites
>> (analogous to the private address ranges 10/8, 172.16/12, and 192.168/16 of
>> IPv4).[12] The addresses include a 40-bit pseudorandom number in the routing
>> prefix intended to minimize the risk of conflicts if sites merge or packets
>> are misrouted into the Internet. Despite the restricted, local usage of
>> these addresses, their address scope is global, i.e. they are expected to be
>> globally unique."
>> 
>> I am trying to set up a local IPv6 network and am curious why all the
>> examples I come accross do not seem to use the 40-bit pseudorandom number?
>> What should I do? Use something like fd00::1234, or incorporate something
>> like the interface's MAC address into the address? It'd make the address
>> quite unreadable though.
>> 
>> Thanks,
>> Jeroen
>> 
>> --
>> http://goldmark.org/jeff/stupid-disclaimers/
>> http://linuxmafia.com/~rick/faq/plural-of-virus.html
>> 
>> 
> 
> 
> 
> -- 
> Ray Soucy
> 
> Epic Communications Specialist
> 
> Phone: +1 (207) 561-3526
> 
> Networkmaine, a Unit of the University of Maine System
> http://www.networkmaine.net/

Re: IPv6 fc00::/7 — Unique local addresses

[Ray Soucy]

For for all intents and purposes if you're looking for RFC1918 style
space in IPv6 you should consider the block FD00::/8 not FC00::/7 as
the FC00::/8 space is reserved in ULA for assignment by a central
authority (who knows why, but with that much address space nobody
really cares).

People may throw a fit at this, but as far as I'm concerned FD00::/8
will never leave the edge of our network (we null route ULA space
before it can leak out, just like you would with RFC1918 space).  So
you can pretty much use it has you see fit.  If you want to keep your
ULA space short there is nothing stopping you from using something
like FD00::1 as a valid address.

You could embed your ASN into it or some other identifier if you want
to avoid conflicts with other non-routed address space which should
never enter or leave your network from the outside, but I'm just not
seeing the practical application for this.

On Wed, Oct 20, 2010 at 5:48 PM, Jeroen van Aart  wrote:
> 
>
> According to http://en.wikipedia.org/wiki/IPv6_address#Special_addresses an
> fc00::/7 address includes a 40-bit pseudo random number:
>
> "fc00::/7 — Unique local addresses (ULA's) are intended for local
> communication. They are routable only within a set of cooperating sites
> (analogous to the private address ranges 10/8, 172.16/12, and 192.168/16 of
> IPv4).[12] The addresses include a 40-bit pseudorandom number in the routing
> prefix intended to minimize the risk of conflicts if sites merge or packets
> are misrouted into the Internet. Despite the restricted, local usage of
> these addresses, their address scope is global, i.e. they are expected to be
> globally unique."
>
> I am trying to set up a local IPv6 network and am curious why all the
> examples I come accross do not seem to use the 40-bit pseudorandom number?
> What should I do? Use something like fd00::1234, or incorporate something
> like the interface's MAC address into the address? It'd make the address
> quite unreadable though.
>
> Thanks,
> Jeroen
>
> --
> http://goldmark.org/jeff/stupid-disclaimers/
> http://linuxmafia.com/~rick/faq/plural-of-virus.html
>
>



-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/

Re: IPv6 fc00::/7 — Unique local addresses

[Owen DeLong]

On Oct 20, 2010, at 10:28 PM, Mark Andrews wrote:

> 
> In message <4cbfc1d0.60...@apolix.co.za>, Graham Beneke writes:
>> On 21/10/2010 02:41, Owen DeLong wrote:
>>> On Oct 20, 2010, at 5:21 PM, Jeroen van Aart wrote:
 Someone advised me to use GUA instead of ULA. But since for my purposes th
>> is is used for an IPv6 LAN would ULA not be the better choice?
 
>>> IMHO, no. There's no disadvantage to using GUA and I personally don't think
>> ULA really serves a purpose. If you want to later connect this
>>> LAN to the internet or something that connects to something that connects t
>> o something that connects to the internet or whatever, GUA provides
>>> the following advantages:
>>> +   Guaranteed uniqueness (not just statistically probable uniquene
>> ss)
>>> +   You can route it if you later desire to
>>> 
>>> Since ULA offers no real advantages, I don't really see the point.
>> 
>> Someone insisted to me yesterday the RFC1918-like address space was the 
>> only way to provide a 'friendly' place for people to start their journey 
>> in playing with IPv6. I think that the idea of real routable IPs on a 
>> lab network daunts many people.
>> 
>> I've been down the road with ULA a few years back and I have to agree 
>> with Owen - rather just do it on GUA.
> 
> Your throwing the baby out with the bath water here.
> 
> ULA, by itself, is a painful especially when you have global IPv4
> reachability as you end up with lots of timeouts.  This is similar
> to have a bad 6to4 upsteam link.  Just don't go there.
> 
> ULA + PA works and provides stable internal addresses when your
> upstream link in down the same way as RFC 1918 provides stable
> internal addressing for IPv4 when your upstream link is down.
> 
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 talk to the world using PA addresses, directly for IPv6 and
> indirectly via PNAT for IPv4.  These can change over time.
> 
Or, if you don't want your IPv6 addresses to change over time, you can
get a prefix from your friendly RIR.

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

One over which you have little or no control unless you are running
a 6to4 gateway of your own and can guarantee that nobody pretends
to be one that is topologically closer to any of your users.

>> I was adding IPv6 to a fairly large experimental network and started 
>> using ULA. The local NREN then invited me to peer with them but I 
>> couldn't announce my ULA to them. They are running a 'public Internet' 
>> network and have a backbone that will just filter them.
>> 
>> I think that the biggest thing that trips people up is that they think 
>> that they'll just fix-it-with-NAT to get onto the GUA Internet. Getting 
>> your own GUA from an RIR isn't tough - rather just do it.
> 
> 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

Try again.

Owen

Re: IPv6 fc00::/7 — Unique local addresses

[Owen DeLong]

On Oct 20, 2010, at 10:07 PM, Mark Smith wrote:

> On Thu, 21 Oct 2010 06:38:33 +0200
> Graham Beneke  wrote:
> 
>> On 21/10/2010 03:49, Matthew Kaufman wrote:
>>> On 10/20/2010 5:51 PM, Owen DeLong wrote:
 
 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.
>>> 
>>> Is this happening now with RFC 1918 addresses and IPv4?
>> 
>> I have seen this in some small providers. Doesn't last long since the 
>> chance of collision is high. It then becomes a VPN.
>> 
 Part 3 will be when that same provider (or some other provider in the
 same boat) takes the next step and starts trading routes of ULA space
 with other provider(s).
>>> 
>>> Is this happening now with RFC 1918 addresses and IPv4?
>> 
>> I've seen this too. Once again small providers who pretty quickly get 
>> caught out by collisions.
>> 
>> The difference is that ULA could take years or even decades to catch 
>> someone out with a collision. By then we'll have a huge mess.
>> 
> 
> I don't think there is a difference. The very small providers are
> the ones who make the stupid mistakes, it's the larger ones that do the
> right thing because it is in their operational interests. Operational
> competence, and the resulting increased reliability, is one of the
> attributes customers of ISPs value highly.
> 
> If any of the Tier-1s don't route ULA address space, then it is useless
> compared to global addresses that *are* routed by *all* the Tier-1s. As
> the Tier-1s also hire competent networking people, they'll also
> understand the scaling issues of the ULA address space, and why it
> shouldn't be globally routed. Competent networking people also exist at
> the lower tiers as well.
> 
Ah, but, since statistically probable Uniqueness is present, I'm betting
eventually some combination of Tier-1s will get bought off to route ULA
and then the flood gates open.

Tier-1s are famous for having their sales and accounting departments
override good engineering practices on a somewhat regular basis.

With RFC-1918 this couldn't happen because collisions meant it
simply wouldn't work. ULA has no such impediment.

> If operators just blindly accept and implement what sales people tell
> them to, then those operators aren't operators. They're mindless drones
> - and the rest of the people operating the Internet will protect the
> Internet from them. Darwin eventually gets rid of those operators
> and the ISP that employ them.
> 
There's a difference between blind acceptance and adherence to a
direct overriding order from the guy that signs your paycheck. I'm sure
they will attempt to fight the good fight, but, in the end, $$ tend to trump
good engineering unless what the $$ want simply can't be made to work.

> Since ULAs could be used as DoS attack sources, they'll also likely be
> filtered out by most people as per BCP38.
> 
Maybe... Given what I've seen with RFC-1918 and other BCP38 violations,
I lack your faith.

Owen

Re: IPv6 fc00::/7 — Unique local addresses

[Owen DeLong]

On Oct 20, 2010, at 9:30 PM, Graham Beneke wrote:

> On 21/10/2010 02:41, Owen DeLong wrote:
>> On Oct 20, 2010, at 5:21 PM, Jeroen van Aart wrote:
>>> Someone advised me to use GUA instead of ULA. But since for my purposes 
>>> this is used for an IPv6 LAN would ULA not be the better choice?
>>> 
>> IMHO, no. There's no disadvantage to using GUA and I personally don't think 
>> ULA really serves a purpose. If you want to later connect this
>> LAN to the internet or something that connects to something that connects to 
>> something that connects to the internet or whatever, GUA provides
>> the following advantages:
>>  +   Guaranteed uniqueness (not just statistically probable 
>> uniqueness)
>>  +   You can route it if you later desire to
>> 
>> Since ULA offers no real advantages, I don't really see the point.
> 
> Someone insisted to me yesterday the RFC1918-like address space was the only 
> way to provide a 'friendly' place for people to start their journey in 
> playing with IPv6. I think that the idea of real routable IPs on a lab 
> network daunts many people.
> 
They should get less daunted. You can always put a firewall with a deny all 
policy or an air-gap in front of it if you don't want to talk to the internet.

> I've been down the road with ULA a few years back and I have to agree with 
> Owen - rather just do it on GUA.
> 
Thanks.

> I was adding IPv6 to a fairly large experimental network and started using 
> ULA. The local NREN then invited me to peer with them but I couldn't announce 
> my ULA to them. They are running a 'public Internet' network and have a 
> backbone that will just filter them.
> 
Uh huh. Now, imagine if, instead of a small experimental deployment, you had a 
fortune 500 enterprise and instead of an NREN it was an ISP for whom you were a 
major customer... Any bets on which side of that equation gets the policy 
change?

> I think that the biggest thing that trips people up is that they think that 
> they'll just fix-it-with-NAT to get onto the GUA Internet. Getting your own 
> GUA from an RIR isn't tough - rather just do it.
> 
I completely agree.

Owen

Re: IPv6 fc00::/7 — Unique local addresses

[Owen DeLong]

On Oct 20, 2010, at 9:38 PM, Graham Beneke wrote:

> On 21/10/2010 03:49, Matthew Kaufman wrote:
>> On 10/20/2010 5:51 PM, Owen DeLong wrote:
>>> 
>>> 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.
>> 
>> Is this happening now with RFC 1918 addresses and IPv4?
> 
> I have seen this in some small providers. Doesn't last long since the chance 
> of collision is high. It then becomes a VPN.
> 
Correct... The only reason it isn't is because of the high chance of collision.
Due to virtually guaranteed overlapping address conflicts, it doesn't work
with RFC-1918.

ULA solves that "problem" by providing probably unique addresses.

>>> Part 3 will be when that same provider (or some other provider in the
>>> same boat) takes the next step and starts trading routes of ULA space
>>> with other provider(s).
>> 
>> Is this happening now with RFC 1918 addresses and IPv4?
> 
> I've seen this too. Once again small providers who pretty quickly get caught 
> out by collisions.
> 
> The difference is that ULA could take years or even decades to catch someone 
> out with a collision. By then we'll have a huge mess.
> 
Exactly.

Owen

Re: IPv6 fc00::/7 — Unique local addresses

[Owen DeLong]

On Oct 20, 2010, at 6:46 PM, Matthew Kaufman wrote:

> On 10/20/2010 6:20 PM, Mark Smith wrote:
>> 
>> To make it clear, as it seems to be quite misunderstood, you'd have
>> both ULA and global addressing in your network.
> 
> Right. Just like to multihome with IPv6 you would have both PA addresses from 
> provider #1 and PA addresses from provider #2 in your network.
> 
Or PI addresses from an RIR.

> Only nobody wants to do that either.
> 
There are lots of good reasons not to want to do that.

Owen

Re: IPv6 fc00::/7 — Unique local addresses

[Owen DeLong]

>>> 
>> Which is part one of the three things that have to happen to make ULA
>> really bad for the internet.
>> 
>> 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.
>> 
> 
> 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.
> 
_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.

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.

> 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.
> 
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), when
people do bad stuff with it, it will work and since it works, they won't
go read the documentation explaining that what works is a bad
idea.

>> Part 3 will be when that same provider (or some other provider in the
>> same boat) takes the next step and starts trading routes of ULA space
>> with other provider(s).
>> 
>> At that point, ULA = GUA without policy = very bad thing (tm).
>> 
>> Since feature creep of this form is kind of a given in internet history,
>> I have no reason to believe it won't happen eventually with ULA.
>> 
> 
> So I'm not sure I can see much benefit would be of paying a
> huge amount of money to have ULA address space put in only a
> limited part/domain of the global route table. The only way to
> have ULA = GUA is to pay everybody on the Internet to carry it, and
> that is assuming that everybody would be willing to accept the money
> in the first place. That'd be far more expensive than just using GUA
> addresses for global reachability.
> 

No... The way it will work is that use of ULA as pseudo-GUA will
spread slowly like cancer through the network.

When provider A and provider B both have customers throwing lots
of money at them to route their ULA, provider A and provider B will
swallow hard and agree to exchange those routes in both directions.

I wish I had your confidence in people doing the right thing, but,
there are enough examples of RFC-1918 space in the GRT that
I simply can't share your belief that it won't happen with ULA
which doesn't have the reliability problems that RFC-1918 had.

Owen

RE: IPv6 fc00::/7 — Unique local addresses

[George Bonser]

> -Original Message-
> From: Mark Smith
> [mailto:na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org]
> Sent: Wednesday, October 20, 2010 9:41 PM
> To: George Bonser
> Cc: nanog@nanog.org
> Subject: Re: IPv6 fc00::/7 — Unique local addresses
> 
> I agree. One application I'd though of was end-to-end Instant
> Messaging, where, when you wish to transfer a file to the other
> participant, a new SCTP stream is created for the file transfer within
> the existing SCTP connection. Not all that novel, but something that
> would be much easier to do with SCTP than TCP.

The absolute win is the elimination of "head of line" blocking. So if you have 
a large transfer going, that little short IM or even email notification or 
whatever gets sent immediately by being multiplexed into the data stream 
instead of being dumped in at the end of a buffer full of other stuff.  By 
having streams for different sorts of content, it has the potential to conserve 
considerable resources.  Rather than having a separate connection for each type 
of content, you have only one.  Now if they would figure out a good way to load 
balance SCTP, we would be all set.  But the real win is where you have a mix of 
bulk data streams and interactive small data transfers.  The bulk transfer 
doesn't interfere with the interactive experience.  

And there are so many other potential applications like maybe persistent VOIP 
"trunks" between branch offices over a long-lived SCTP connection with each of 
those "trunks" being a stream within one connection.  The applications are 
potentially killer but nobody has really tapped into that area yet.  Heck, 
multicast hasn't really lived up to its potential, either.

Re: IPv6 fc00::/7 ? Unique local addresses

[Mark Smith]

On Thu, 21 Oct 2010 12:44:40 +0800
Adrian Chadd  wrote:

> On Thu, Oct 21, 2010, Graham Beneke wrote:
> 
> > I've seen this too. Once again small providers who pretty quickly get 
> > caught out by collisions.
> > 
> > The difference is that ULA could take years or even decades to catch 
> > someone out with a collision. By then we'll have a huge mess.
> 
> You assume that people simply select ULA prefixes randomly and don't
> start doing linear allocations from the beginning of the ULA range.
> 
> 

Any time there is a parameter that can be configured, there is a
possibility that people will misconfigure it. The only way to
completely prevent that being a possibility is to eliminate the
parameter. We can prevent people from getting addressing wrong by not
putting addresses in the IP header - but I, and I suspect most people,
would prefer their computers not to be a dumb terminal connected to a
mainframe. Or we can make the network robust against misconfiguration,
and put in place things like BCP38.

This is all starting to sound a bit like Chicken Little.

Regards,
Mark.

Re: IPv6 fc00::/7 ? Unique local addresses

[Joel Jaeggli]

On 10/20/10 9:44 PM, Adrian Chadd wrote:
> On Thu, Oct 21, 2010, Graham Beneke wrote:
> 
>> I've seen this too. Once again small providers who pretty quickly get 
>> caught out by collisions.
>>
>> The difference is that ULA could take years or even decades to catch 
>> someone out with a collision. By then we'll have a huge mess.

having merged datacenters with multiple overlapping v4 prefixes I'll
just observe that this is inevitable in v4, you can take steps that make
it less likely to impact you in v6.

> You assume that people simply select ULA prefixes randomly and don't
> start doing linear allocations from the beginning of the ULA range.

actually I assume they're going to just assign the whole botton half to
themselves like they do with 10/8 since using fc01::/8 is clearly more work.

If you do assign randomly the probability of someone deliberately
assigning the same /48 for use in their network seems pretty low, you're
a heck of a lot better off than with rfc 1918.

> 
> 
> 
> Adrian
> 
> 

Re: IPv6 fc00::/7 — Unique local addresses

[Mark Smith]

On Thu, 21 Oct 2010 06:38:33 +0200
Graham Beneke  wrote:

> On 21/10/2010 03:49, Matthew Kaufman wrote:
> > On 10/20/2010 5:51 PM, Owen DeLong wrote:
> >>
> >> 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.
> >
> > Is this happening now with RFC 1918 addresses and IPv4?
> 
> I have seen this in some small providers. Doesn't last long since the 
> chance of collision is high. It then becomes a VPN.
> 
> >> Part 3 will be when that same provider (or some other provider in the
> >> same boat) takes the next step and starts trading routes of ULA space
> >> with other provider(s).
> >
> > Is this happening now with RFC 1918 addresses and IPv4?
> 
> I've seen this too. Once again small providers who pretty quickly get 
> caught out by collisions.
> 
> The difference is that ULA could take years or even decades to catch 
> someone out with a collision. By then we'll have a huge mess.
> 

I don't think there is a difference. The very small providers are
the ones who make the stupid mistakes, it's the larger ones that do the
right thing because it is in their operational interests. Operational
competence, and the resulting increased reliability, is one of the
attributes customers of ISPs value highly.

If any of the Tier-1s don't route ULA address space, then it is useless
compared to global addresses that *are* routed by *all* the Tier-1s. As
the Tier-1s also hire competent networking people, they'll also
understand the scaling issues of the ULA address space, and why it
shouldn't be globally routed. Competent networking people also exist at
the lower tiers as well.

If operators just blindly accept and implement what sales people tell
them to, then those operators aren't operators. They're mindless drones
- and the rest of the people operating the Internet will protect the
Internet from them. Darwin eventually gets rid of those operators
and the ISP that employ them.

Since ULAs could be used as DoS attack sources, they'll also likely be
filtered out by most people as per BCP38.

Regards,
Mark.

Re: IPv6 fc00::/7 ? Unique local addresses

[Adrian Chadd]

On Thu, Oct 21, 2010, Graham Beneke wrote:

> I've seen this too. Once again small providers who pretty quickly get 
> caught out by collisions.
> 
> The difference is that ULA could take years or even decades to catch 
> someone out with a collision. By then we'll have a huge mess.

You assume that people simply select ULA prefixes randomly and don't
start doing linear allocations from the beginning of the ULA range.




Adrian

Re: IPv6 fc00::/7 — Unique local addresses

[Mark Smith]

On Wed, 20 Oct 2010 20:12:11 -0700
"George Bonser"  wrote:

> > 
> > * Stream Control Transport Protocol, first spec'd in 2000 (couldn't
> >   be deployed widely in IPv4 because of NATs)
> 
> I would dearly love to see SCTP take off.  There are so many great potential 
> applications for that protocol that it can boggle.  Any type of connection 
> between two things that might have several different kinds of data going back 
> and forth at the same time could greatly benefit.
> 

I agree. One application I'd though of was end-to-end Instant
Messaging, where, when you wish to transfer a file to the other
participant, a new SCTP stream is created for the file transfer within
the existing SCTP connection. Not all that novel, but something that
would be much easier to do with SCTP than TCP.


Regards,
Mark. 

Re: IPv6 fc00::/7 — Unique local addresses

[Mark Smith]

On Thu, 21 Oct 2010 14:29:11 +1100
Mark Andrews  wrote:

> 
> In message <4cbfa9bb.9030...@matthew.at>, Matthew Kaufman writes:
> > ULA + PA can have the same problems, especially if your ULA is 
> > inter-organization ULA, which was one of the cases under discussion.
> 
> Which still isn't a problem.  Presumably you want your inter-organization
> traffic to use ULA addresses to talk to each other so you setup the
> address selection rules to do just that.  That requires new rules
> being distributed to all nodes that need to talk to the other site.
> Presumable DHCPv6 could do this.  If there isn't yet a DHCP option
> to request address selection rules we need to define one.

One is being defined -

https://datatracker.ietf.org/doc/draft-fujisaki-6man-addr-select-opt/

>  Use a
> VPN between the organisations so you fate share.  If you have a
> private interconnect then the VPN becomes the backup.
> 
> > Matthew Kaufman
> > 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

RE: IPv6 fc00::/7 — Unique local addresses

[George Bonser]

> 
> * Stream Control Transport Protocol, first spec'd in 2000 (couldn't
>   be deployed widely in IPv4 because of NATs)

I would dearly love to see SCTP take off.  There are so many great potential 
applications for that protocol that it can boggle.  Any type of connection 
between two things that might have several different kinds of data going back 
and forth at the same time could greatly benefit.

Re: IPv6 fc00::/7 — Unique local addresses

[Mark Smith]

On Wed, 20 Oct 2010 19:50:06 -0700
Matthew Kaufman  wrote:

> On 10/20/2010 7:27 PM, Mark Smith wrote:
> >
> > * Stream Control Transport Protocol, first spec'd in 2000 (couldn't
> >be deployed widely in IPv4 because of NATs)
> "because of NATs" s/b "because certain parties refused to acknowledge 
> that encapsulation of SCTP in UDP would have operational advantages 
> sufficient to outweigh the disadvantages".
> 
> SCTP only gets you 90% of the way there, but it is a lot closer than 
> today's TCP is.
> 

Which is why there is also work going on at the network layer, both on
the end-hosts via HIP or Shim6, and in the network, such as LISP.

Ultimately, this is a hard problem to solve. There is no easy solution,
otherwise it'd already exist, and have existed at least 10 years ago -
as that is at least how long people have been working on trying to
solve it.

As there is no easy and perfect solution, then we need to accept that
we're going to have to make trade offs to be able to get closer to
solving it. In other words, a better solution, even if it isn't
perfect, is better. The question is what trade offs are acceptable to
make?

We know and have experienced the many drawbacks of NAT, including such
things as restricting deployment of new and better transport protocols
like SCTP, DCCP, and maybe multipath TCP if the NAT boxes inspect and
drop unknown TCP options, and forcing the nature of Internet
applications to be client-server, even when a peer-to-peer application
communications architecture would be far more reliable, scalable and
secure. As NAT ultimately was about conserving address space, and IPv6
solves that problem, it is worth exploring other options that weren't
possible with IPv4 and/or IPv4 NAT.

Regards,
Mark.

Re: IPv6 fc00::/7 — Unique local addresses

[Mark Smith]

On Wed, 20 Oct 2010 21:15:35 -0500
James Hess  wrote:

> On Wed, Oct 20, 2010 at 8:46 PM, Matthew Kaufman  wrote:
> > On 10/20/2010 6:20 PM, Mark Smith wrote:
> > Right. Just like to multihome with IPv6 you would have both PA addresses
> > from provider #1 and PA addresses from provider #2 in your network.
> > Only nobody wants to do that either.
> 
> A perfectly valid way to multihome, right?Setup each host with two
> IP addresses,
> one in each PA range. Use multiple DNS records, to indicate all
> the host's pairs of IPs.
> If an ISP link goes down,  all the clients' should automatically try
> resend the unack'ed packets to the
> DNS name's  other IPs in 10 or 11 seconds, and recover, without having
> to reconnect, right? right??[ No   :(  ]
> 
> Automatic  failover to other multihomed IPs  seems to always have been
> left missing from the TCP protocols, for some reason or another.
> 
> Probably good reasons, but that  multihoming strategy isn't a very
> good one, for now,
> due to the disruption of active connections,   and bad client
> programs that won't look for other DNS records,
> even when trying to establish a new connection.
> 
> Perhaps one day, there will be a truly reliable transport protocol,
> and an  API  that allows a bind()
> against multiple IPs and  a  connect()

* Stream Control Transport Protocol, first spec'd in 2000 (couldn't
  be deployed widely in IPv4 because of NATs)

* "TCP Extensions for Multipath Operation with Multiple Addresses"
https://datatracker.ietf.org/doc/draft-ietf-mptcp-multiaddressed/

and

"Architectural Guidelines for Multipath TCP Development"
https://datatracker.ietf.org/doc/draft-ietf-mptcp-architecture/

> to all a target host's IPs instead of just one, so both hosts can
> learn of each other's IP addresses
> that are offered to be used for that connection, then   "multiple PA
> IP addresses"
> would be a  technically viable multi-homing strategy.
> 
> 
> --
> -Jh