Subject: [v6ops] draft-liu-v6ops-ula-usage-analysis

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 14 Mar 2013 14:46:23 +0000

In the meeting at IETF 86, we discussed

http://datatracker.ietf.org/doc/draft-liu-v6ops-ula-usage-analysis
http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis
  "Guidance of Using Unique Local Addresses", Bing Liu, Sheng Jiang,
  Cameron Byrne, 25-Feb-13

and the hum supported making that a working group draft. In this note, I'm asking for ratification on the list - whether you agree or disagree, I'd appreciate your thoughts.

---

From: Victor Kuarsingh <[email-masked]>
Date: Thu, 14 Mar 2013 11:00:30 -0400

I support a draft that describes ULAs with the following principles.

- Early document text separating RFC1918 from ULAs (that RFC1819 != ULA)
- I am ok with describing general use cases (I think we cannot enumerate
all possible specific cases yet - IPv6 has not found it's way in enough
places to understand the full extent of what and where ULAs can be used)
- text needs to cover the drawbacks of using ULAs in those general cases
(I.e. Host using ULA, then requires future Internet connectivity etc).
- I also think that we should not specifically "recommend" or "not
recommend" specific options.  The key is to provide the right description
of the drawbacks, issues and challenges that can arise

If the draft takes on that form, I think it can provide valuable guidance
(better then having people guess and use an incomplete set of
data/experience to figure out how/when to use ULAs).

Regards,

Victor K

On 2013-03-14 10:46 AM, "Fred Baker (fred)" <[email-masked]> wrote:

>and the hum supported making that a working group draft. In this note,
>I'm asking for ratification on the list - whether you agree or disagree,
>I'd appreciate your thoughts.
>_______________________________________________
>v6ops mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/v6ops

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Mar 2013 15:03:52 +0000

Since I wasn't there, let me hummmmm for adoption. The fact that how to
use ULAs is a bit contentious is a very good reason for publishing
this document.

Regards
   Brian

---

From: Jong-Hyouk Lee <[email-masked]>
Date: Thu, 14 Mar 2013 11:09:07 -0400

I support this draft.

Regarding some descriptions of general use cases and specific use cases,
I'd like to encourage the authors to keep both: first give the general use
cases and then give some specific use cases. In this way, this draft would
provide better understanding of the ULA use to people.

Cheers.

-- 
RSM Department, TELECOM Bretagne, France
Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random

#email: jonghyouk (at) gmail (dot) com
#webpage: http://sites.google.com/site/hurryon/

---

From: Sean Stuart <[email-masked]>
Date: Thu, 14 Mar 2013 11:09:46 -0400

I support this as a working group item.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 14 Mar 2013 15:27:07 +0000

> - Early document text separating RFC1918 from ULAs (that RFC1819 != ULA)

I suspect that's code for something it doesn't well express.

RFC 1918 provides several prefixes that can be used within a routing domain and are not advertised outside it. ULAs are a more scalable way to implement that concept in IPv6. From that perspective, one could argue that a ULA has an obvious relationship to an RFC 1918 prefix.

RFC 1918 prefixes are often used behind a translator, which enables traffic to cross the boundary and have a global address on the far side. I think this is the usage that you (and many) object to.

I'm fine with the recommendation, but I think that it needs to be stated in a manner that someone not from our community would be able to understand.

Examples that I consider good uses of ULAs depend on the premise that the ULA is only advertised within a limited domain. The reference to  draft-baker-v6ops-b2b-private-routing-00.txt, for example, is a condition of controlled trust: two business entities want to exchange private routing among a set of systems used by both business entities but whose identity is not shared. The ULA is used as a means of controlling routing without disclosing identity. Any company has some systems that are only used internally, and access to which is filtered at the firewall. A ULA eliminates the need for the firewall rule; since it is not advertised outside, the system(s) is unreachable from the outside. And so on.

---

From: Victor Kuarsingh <[email-masked]>
Date: Thu, 14 Mar 2013 13:22:10 -0400

On 2013-03-14 11:27 AM, "Fred Baker (fred)" <[email-masked]> wrote:

>RFC 1918 provides several prefixes that can be used within a routing
>domain and are not advertised outside it. ULAs are a more scalable way to
>implement that concept in IPv6. From that perspective, one could argue
>that a ULA has an obvious relationship to an RFC 1918 prefix.

Agreed, there are some definite relationships, and there are some
differences.  One such difference, which if used correctly, you can
connect two domains using ULAs and not need a NAT box in the middle given
prefixes which are not expected to overlap (the pain we have with
converging networks using RFC1918 with typical overlap).  I think my point
(perhaps not made well), was that ULAs and RFC1918 are not interchangeable
(there are some differences).

>
>RFC 1918 prefixes are often used behind a translator, which enables
>traffic to cross the boundary and have a global address on the far side.
>I think this is the usage that you (and many) object to.

I am not as opposed to this as others are.  But I agree, the use case of
ULA+NPTv6 and ULA+NAT66 are a bit more contentious.  My point was I
(personally) don't need to see a "don't do it", but think the drawbacks
need to be well described (or points to references which describe this).
I suspect others a bit more polarized on this particular topic.  I would
also think we should not recommend ULA-NPTv6 either.

>
>I'm fine with the recommendation, but I think that it needs to be stated
>in a manner that someone not from our community would be able to
>understand.

Agreed. This document is most useful for people who are not typical RFC
document consumers.  Therefore extra attention needs to be applied to put
it into a tone which makes sense for non-IETF frequent flyers.

Regards,

Victor K

---

From: Doug Barton <[email-masked]>
Date: Thu, 14 Mar 2013 11:10:37 -0700

>> I suspect that's code for something it doesn't well express.

A very well-turned phrase, Fred. :)

> converging networks using RFC1918 with typical overlap).

You can do that with 1918 addresses too. In fact I'm at a loss to see 
how you could do that with ULA in a way that you could not do it with 
1918 space.

> I think my point

Can you describe in detail what those differences are, and why they are 
important to you?

I'm not saying you're wrong, just that I'd like to understand exactly 
what you're trying to convey.

Doug

---

From: Bill Jouris <[email-masked]>
Date: Thu, 14 Mar 2013 11:14:27 -0700 (PDT)

Agree.  

We need to get more information out there on *how* various features of IPv6 can be usefully implemented.

Bill Jouris
Inside Products, Inc.
www.insidethestack.com
831-659-8360
925-855-9512 (direct)

--- On Thu, 3/14/13, Fred Baker (fred) <[email-masked]> wrote:

From: Fred Baker (fred) <[email-masked]>
Subject: [v6ops] draft-liu-v6ops-ula-usage-analysis
To: "v6ops WG" <[email-masked]>
Date: Thursday, March 14, 2013, 7:46 AM

---

From: Victor Kuarsingh <[email-masked]>
Date: Thu, 14 Mar 2013 14:53:30 -0400

Doug,

>how you could do that with ULA in a way that you could not do it with

Well the statement is somewhat dependant on how the two domains were
addressed (I.e. Did they use the whole RFC1918 space, was it optimal [I.e.
Spare usage with poor summarization etc]).

So, an example (just one example) would be Network-A and Network-B.
Network-A is using 10/8 with usage across the entire block.  Network-B is
using 10/8 with usage across the block as well.  Assuming no renumbering
(which can be extremely difficult in some places) to connect these two
network domains, you may need a NAT box in the middle or some other way to
get stuff to communication across the overlapping domains (in fact I have
personally had to do this more then once converging networks together).

In the ULA/IPv6 example, we take the same Network-A and Network-B.
Network-A uses FD00:<prefixA>/48 and assigns it to the infrastructure.
Network-B uses FD00:<prefixB>/48 and assigns it to the infrastructure.  I
now attempt to connect these two domains.  From an addressing perspective
I do not need a NAT function between networks, I can just route traffic.
Of course I may need to change some routing policy, filtering rules and
other items depending on how each network built up their independent
(pre-converged) policies.

Using ULAs, one has [arguably] more flexibility in some cases vs. what we
are typically used to in RFC1918 land.  This is due to the amount of
overall space available to generate ULA prefixes.  So my position is that
although I may not expect to need to have global connectivity with ULAs, I
have different expectations as to what I can do with this environment in
the future. (Section 4.3 RFC4193)

Also, with RFC1918, some SPs (and enterprises) may have run out of space.
This is much less likely in ULA/IPv6 given that a run out of my /48 block
(likely prefix run out, not IPv6 address run out), I can spawn a second,
third, fourthŠ block and keep going.

A nice side point supporting ULA is that my network policy can remain
largely the same (filtering, routing, etc) if it's build around FC00::/7

>Can you describe in detail what those differences are, and why they are

There are places in IPv4 land where I may not have been able to use global
IPv4 addresses (I.e. If I needed a /8, /9, /10 as a non-large company) so
I would have been stuck with RFC1918.  In IPv6, you can feasibly get
addresses that you need up front.  You may want to do this if you may
expect to have global connectivity in the future (of course you can use
ULA+NAT, but there are options which were not necessary available in
IPv4).  This means that when evaluating addressing iPv6, as part of the
ULA considerations, you can choose to use GUA for future use options.  So,
one may artificially put themselves at a disadvantage with ULAs which may
be avoidable (but was less of an option with IPv4 due to space
constraints). If people believe that ULAs are just a new form of RFC1918,
they may default to ULAs needlessly.

>From a usage perspective, in IPv4, one typically gave a host a single IPv4
address. In IPv6, you can assign multiple addresses.  So you can assign a
ULA and a GUA (I know there are questions about source address selection
here).  This option is easy to do and you can then provide connectivity
for both intra-zone flows using ULAs and external zone flows using GUAs.

One may ask why would someone do this? (I.e. Why not use multiple GUA
blocks and treat them differently etc).  Well this is an internal choice
to be made by the operator/enterprise.  Back to the ULA case, if a
business had a GUA/PA space (which may change over time), the ULA space
can be somewhat stable with internal DNS names attached to that (perhaps
you need to renumber later on for the PA space).  I am not saying this is
a good idea, but you can do it.  I personally do this in my home/test but
I don¹t represent a big enough network and endpoints to say it works in
the general case.

Another point, as RFC4193 was written, applications are permitted to use
ULAs in an identical manner as global addresses.  This may cause problems
depending on things are deployed.

(Section 6.1 / RFC4193) "Applications can treat these addresses in an
identical manner as
        any other type of global IPv6 unicast addresses."

Just a few things.. I guess there is room for more discussion.

Regards,

Victor K

---

From: Doug Barton <[email-masked]>
Date: Thu, 14 Mar 2013 12:26:26 -0700

> Spare usage with poor summarization etc]).

So we can summarize by saying that the distinction is that operators are 
less likely to run into overlapping networks with ULA. That is an 
important thing to note, but it's not a functional difference.

> address. In IPv6, you can assign multiple addresses.

You can assign multiple addresses in IPv4 too. That's not actually a 
difference.

>          any other type of global IPv6 unicast addresses."

I don't see how this is different from 1918 space.

Doug

---

From: Tom Taylor <[email-masked]>
Date: Thu, 14 Mar 2013 18:18:19 -0400

Agree.

On 14/03/2013 10:46 AM, Fred Baker (fred) wrote:
> .

---

From: Owen DeLong <[email-masked]>
Date: Thu, 14 Mar 2013 16:25:38 -0700

On Mar 14, 2013, at 11:10 AM, Doug Barton <[email-masked]> wrote:

> You can do that with 1918 addresses too. In fact I'm at a loss to see how you could do that with ULA in a way that you could not do it with 1918 space.

If both sites are using 10.0.0.0/8 in an overlapping manner, then connecting them via routers does not yield goodness. OTOH, if both sites are using appropriately random ULA prefixes, the odds of an overlap are very low.
Thus it is far more likely with ULA that connecting two sites via routers and achieving the desired result is possible than it is with RFC-1918. OTOH, it's even more likely with GUA.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 14 Mar 2013 16:21:46 -0700

> - Early document text separating RFC1918 from ULAs (that RFC1819 != ULA)

I would like to see this part include as part of the differentiation that the use of ULA
with NAT or NPT is not recommended as in the traditional use of RFC-1918.

---

From: Doug Barton <[email-masked]>
Date: Thu, 14 Mar 2013 16:35:17 -0700

On 03/14/2013 04:25 PM, Owen DeLong wrote:
> If both sites are using 10.0.0.0/8 in an overlapping manner, then connecting them via routers does not yield goodness.

Of course, but that's not a technical difference between ULA and 1918. 
As I pointed out in my reply to Victor, the distinction is that it's 
less likely to happen with ULA, which is worth noting of course.

Doug

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 15 Mar 2013 04:35:12 +0100 (CET)

> I'm asking for ratification on the list - whether you agree or disagree,

I like to see it as a WG draft.

However, I would like to discourage usage of ULAs for deployment with a 
default route in hosts. Unless there is a way to make the hosts only use 
its ULA address to talk to only other ULA addresses, I don't like to see 
them being used at all.

The whole kludge with NPT when traversing onto the public Internet is in 
my opinion not good and the fact that the whole IPv6 model wasn't designed 
with routing in mind from the beginning is something I consider very 
unfortunate. When RAs are sent and an on-link prefix is being announced, 
there should be routing information included so that hosts could be 
configured with ULA but only use this address for communication with other 
ULA, and even perhaps only with a netmask that matches the ULA prefix used 
in the specific home.

I asked in the jabber room the other day and the answer I got was that the 
gateway could send ICMP messages saying an ULA packet sent via the default 
route didn't reach its destination, but this is a very chatty way of 
achieving the same goal.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Fri, 15 Mar 2013 15:00:24 +1100

> its ULA address to talk to only other ULA addresses, I don't like to see 

Well one can certainly configure nodes to preference ula when talking
to ula and depreference ula when talking to anything else.

> route didn't reach its destination, but this is a very chatty way of 

Yes, it is chatty.

One needs to be able to null route fc00::/7 yet still have
f[cd]xx:xxxx::/48 route installed for each f[cd]xx:xxxx::/48 in use
on the link.

If one only installed ::/0 if there is a non fc00::/7 prefix and
installed a null route for fc00::/7 along with a next hop for
f[cd]xx:xxxx::/48 if there is a f[cd]xx:xxxx::/48 or longer prefix
advertised in the RA.  This would address most of these issues.  It
would only require a bit in the f[cd]xx:xxxx::/48 prefix announcement
to say to do this.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 15 Mar 2013 07:07:08 +0100 (CET)

On Fri, 15 Mar 2013, Mark Andrews wrote:

> Well one can certainly configure nodes to preference ula when talking to 
> ula and depreference ula when talking to anything else.

Remotely? In that case, how? I don't want the nodes seeing the RAs to 
believe that there is IPv6 GUA Internet connectivity just because they 
happen to get a ULA address using SLAAC.

> f[cd]xx:xxxx::/48 route installed for each f[cd]xx:xxxx::/48 in use on 
> the link.

That's fine.

> would only require a bit in the f[cd]xx:xxxx::/48 prefix announcement to 
> say to do this.

What bit in the announcement are you referring to?

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 15 Mar 2013 08:17:19 +0000

On 14/03/2013 18:53, Victor Kuarsingh wrote:
...
> network domains, you may need a NAT box in the middle 

And there are plenty of cheap NATs that simply will not work
if 10.0.0.1 exists on both sides of the NAT.

     Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 15 Mar 2013 07:05:56 -0700

On Thu, Mar 14, 2013 at 7:46 AM, Fred Baker (fred) <[email-masked]> wrote:

> and the hum supported making that a working group draft. In this note, I'm
> asking for ratification on the list - whether you agree or disagree, I'd
> appreciate your thoughts.
>

I do not support adoption of this document, because I'd argue that we as a
community do not yet have enough experience with using ULAs compared to
global addresses.

I would support a draft that discussed and reported on operational
experience obtained from actually using ULAs, but there does not seem to be
much of that in this draft.

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 15 Mar 2013 14:28:11 +0000

Hi, Lorenzo,

For my understanding, your ask too much for adoption call according to the IETF process. The adoption only means the WG agree it is an important work, the WG should works on. It is not necessary we already have the best content. It is for WGLC.

I think you agree that ULA is an important topic that v6ops should do something on it, but think the current need much more concrete content from real experience to be published.

If your agree my above observation, the right thing to do is v6ops WG adopt this draft first, then, have the authors (maybe call more contributions from WG too) to continue work on it. We will come to decide whether the content is mature enough for publication during WGLC or whether to launch WGLC at all.

Best regards,

Sheng

________________________________
From: [email-masked] [[email-masked]] on behalf of Lorenzo Colitti [[email-masked]]
Sent: 15 March 2013 22:05
To: Fred Baker (fred)
Cc: v6ops WG
Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis

On Thu, Mar 14, 2013 at 7:46 AM, Fred Baker (fred) <[email-masked]<mailto:[email-masked]>> wrote:
http://datatracker.ietf.org/doc/draft-liu-v6ops-ula-usage-analysis
http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis
  "Guidance of Using Unique Local Addresses", Bing Liu, Sheng Jiang,
  Cameron Byrne, 25-Feb-13

I do not support adoption of this document, because I'd argue that we as a community do not yet have enough experience with using ULAs compared to global addresses.

I would support a draft that discussed and reported on operational experience obtained from actually using ULAs, but there does not seem to be much of that in this draft.

---

From: joel jaeggli <[email-masked]>
Date: Fri, 15 Mar 2013 10:51:14 -0400

> if 10.0.0.1 exists on both sides of the NAT.
you generally have to have an actual collision of subnets for that to 
happen. it's not enough to break things to simply have non-overlapping 
rfc-1918 ranges on both sides.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 15 Mar 2013 14:54:11 +0000

> and the hum supported making that a working group draft. In this note, I'm asking for ratification on the list - whether you agree or disagree, I'd appreciate your thoughts.

We're having a good discussion of the draft, which is to be encouraged.

The initial purpose of this thread was to determine whether it should be adopted by the working group. I have heard a number of voices in favor and none opposed. So what I need to hear now, if there are any, is those that are opposed.

---

From: Arturo Servin <[email-masked]>
Date: Fri, 15 Mar 2013 10:55:36 -0400

I have mixed feelings about this draft.

	In one hand I think it is valuable to have a document to inform about
ULAs usage. On the other hand I am not very comfortable in the way the
document recommends ULAs and I agree with Lorenzo that we need more
deployment experience to have a good outcome.

	Perhaps reading a new version with the comments that has been addressed
in the list I would move to neutral/no-support to support.

/as

On 15/03/2013 10:28, Sheng Jiang wrote:
> Hi, Lorenzo,
> 
>  
> 
> For my understanding, your ask too much for adoption call according to
> the IETF process. The adoption only means the WG agree it is an
> important work, the WG should works on. It is not necessary we already
> have the best content. It is for WGLC.
> 
>  
> 
> I think you agree that ULA is an important topic that v6ops should do
> something on it, but think the current need much more concrete content
> from real experience to be published.
> 
>  
> 
> If your agree my above observation, the right thing to do is v6ops WG
> adopt this draft first, then, have the authors (maybe call more
> contributions from WG too) to continue work on it. We will come to
> decide whether the content is mature enough for publication during WGLC
> or whether to launch WGLC at all.
> 
>  
> 
> Best regards,
> 
>  
> 
> Sheng
> 
> ------------------------------------------------------------------------
> *From:* [email-masked] [[email-masked]] on behalf of
> Lorenzo Colitti [[email-masked]]
> *Sent:* 15 March 2013 22:05
> *To:* Fred Baker (fred)
> *Cc:* v6ops WG
> *Subject:* Re: [v6ops] draft-liu-v6ops-ula-usage-analysis
> 
>     and the hum supported making that a working group draft. In this
>     note, I'm asking for ratification on the list - whether you agree or
>     disagree, I'd appreciate your thoughts.
> 
> 
> I do not support adoption of this document, because I'd argue that we as
> a community do not yet have enough experience with using ULAs compared
> to global addresses.
> 
> experience obtained from actually using ULAs, but there does not seem to
> be much of that in this draft.
> 
>

---

From: Victor Kuarsingh <[email-masked]>
Date: Fri, 15 Mar 2013 11:42:21 -0400

From:  Lorenzo Colitti <[email-masked]>

>I would support a draft that discussed and reported on operational experience
obtained from actually using ULAs, but there does not seem to be much of that in
>this draft.

[VICTORK]

Although I differ with the position on adoption (I support to adopt), I also
agree with this last statement from Lorenzo.  We do not have enough
experience and testing with ULAs -  hence why any recommendations are
premature (in either direction) IMHO.  I still support an option where we
list deployment options and along with benefits/drawbacks (as understood as
of today).

Regards,

Victor K

---

From: Mark Smith <[email-masked]>
Date: Fri, 15 Mar 2013 14:05:13 -0700 (PDT)

Hi,

I support this becoming a working group draft.

Regards,
Mark.

----- Original Message -----
> To: v6ops WG <[email-masked]>
> Cc: 
> Sent: Friday, 15 March 2013 1:46 AM

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 15 Mar 2013 21:32:47 +0000

Fred,

While I support the idea that we need a draft on ULA as a WG item, I must write that I share Victor, Arturo and Lorenzo's concerns about the current I-D, it is not ready for WGLC

-éric

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Victor Kuarsingh
> Sent: jeudi 14 mars 2013 16:01
> To: Fred Baker (fred); v6ops WG
> - I am ok with describing general use cases (I think we cannot enumerate all
> possible specific cases yet - IPv6 has not found it's way in enough places
> to understand the full extent of what and where ULAs can be used)
> recommend" specific options.  The key is to provide the right description of
> the drawbacks, issues and challenges that can arise
> 
> >I'm asking for ratification on the list - whether you agree or

---

From: Shishio Tsuchiya <[email-masked]>
Date: Fri, 15 Mar 2013 18:33:57 -0400

I think the draft is well-written about feature of ULA.
I know a lot of service provider and enterprise who are deployed IPv6 in their network, but I don't know ULA widely deployed network.

IMHO,in this case,we may need experience document before the draft support as WG.
like a RFC6586
https://tools.ietf.org/html/rfc6586
http://tools.ietf.org/html/draft-hazeyama-widecamp-ipv6-only-experience
http://tools.ietf.org/html/draft-janog-softwire-report

I'm not support the draft in this point.
But if the experience document will be published,I will completely support this draft.

Regards,
-Shishio

---

From: Owen DeLong <[email-masked]>
Date: Fri, 15 Mar 2013 17:20:02 -0700

> I know a lot of service provider and enterprise who are deployed IPv6 in their network, but I don't know ULA widely deployed network.

This is a good thing IMHO… ULA deployment really should be the exception, not the rule.

Owen

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sat, 16 Mar 2013 02:02:45 +0000

On Mar 15, 2013, at 5:32 PM, Eric Vyncke (evyncke) <[email-masked]> wrote:

> it is not ready for WGLC

We rarely adopt a draft and leave it unchanged. The real question in adoption is whether the working group is willing to take control of it and turn it into a consensus document as opposed to the dreams of the original author. I expect the draft we publish to be quite a bit different than this one.

---

From: Ray Hunter <[email-masked]>
Date: Tue, 19 Mar 2013 14:10:51 +0100

> and the hum supported making that a working group draft. In this note, I'm asking for ratification on the list - whether you agree or disagree, I'd appreciate your thoughts.
I have a problem with "BCP" status for any draft recommending use of ULA
on Internet connected networks without some health warning, because I'm
not yet convinced that this may not end up being harmful [highly mobile
devices, split horizon, caching].

But let's see where the draft goes from here.

regards,
RayH

---

From: Randy Bush <[email-masked]>
Date: Wed, 20 Mar 2013 08:56:32 +0200

> I have a problem with "BCP" status for any draft recommending use of

+1

randy

---

From: Tim Chown <[email-masked]>
Date: Wed, 20 Mar 2013 07:42:44 +0000

> devices, split horizon, caching].

Informational seems appropriate.

While some of us have been using them in various contexts, unless we hear of widescale, significant deployments, it's difficult to argue for BCP.

Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Mar 2013 08:48:15 +0000

> While some of us have been using them in various contexts, unless we hear of widescale, significant deployments, it's difficult to argue for BCP.

It depends. If the draft says "If you choose to use a ULA prefix, here
are some guidelines on how to do it properly", BCP might be appropriate.
However, an informational description of appropriate deployment scenarios
would be quite OK.

If it says "Use a ULA prefix!", I would certainly object to BCP.

   Brian

---

From: Tim Chown <[email-masked]>
Date: Wed, 20 Mar 2013 09:03:01 +0000

> If it says "Use a ULA prefix!", I would certainly object to BCP.

The homenet arch (which is Informational) is recommending use of ULAs. There are real use cases already identified there, particularly with constrained devices; one of the arch text authors is I believe already producing such things. 

The other arguments made include disconnected operation, and internal connection persistence through ISP-traiggered renumbering events.

A challenge is dealing with multiple internal routers that may generate a /48 ULA, including cases where such devices are initially not connected and are then joined/merged.  In such cases devices in the homenet need to be aware of which ULA prefixes are internal to the home, and thus that should be preferred over GUAs for address selection.

Tim

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 20 Mar 2013 10:15:53 +0100

>>>> "Guidance of Using Unique Local Addresses", Bing Liu, Sheng
>>>> Jiang, Cameron Byrne, 25-Feb-13
>>>>
>>>> and the hum supported making that a working group draft. In
>>>> this note, I'm asking for ratification on the list - whether
>>>> you agree or disagree, I'd appreciate your thoughts.
>>> I have a problem with "BCP" status for any draft recommending use
>>> of ULA on Internet connected networks without some health
>>> warning, because I'm not yet convinced that this may not end up
>>> being harmful [highly mobile devices, split horizon, caching].
>>
>> While some of us have been using them in various contexts, unless
>> we hear of widescale, significant deployments, it's difficult to
>> argue for BCP.
>
> It depends. If the draft says "If you choose to use a ULA prefix,
> here are some guidelines on how to do it properly", BCP might be
> appropriate. However, an informational description of appropriate
> deployment scenarios would be quite OK.
>

I agree with both points.

We consider the ULAs for vehicular networks, although not sure yet
whether the current convenience we have on using them means we should go
that way any further.

Typically one vehicle would be a 'site', yet vehicle-to-vehicle
communications would form another one. just a little larger such site.

This begs for the advice: is the Mobile Router (a router, or 'modem', or
'ECU', or Gateway) deployed in the vehicle making a strict separation
between the vehicle and the outside of the vehicle for these ULAs?
(i.e. dont forward ULA-addresses packets in-out of vehicle).  Or is that
separation done only when connecting to the fixed infrastructure (i.e.
to Internet, with a default route)?

Should we set the L bit (local/global).

Are alternative methods possible for seeting the Global ID possible?
(other than RFC4193, which suggests to rely on the time, EUI-64 and
SHA-1 - each having various constraints: where to get time in a reliable
manner, which EUI-64 of those many in a vehicle, export control.)

Alex

>
> Brian _______________________________________________ v6ops mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>
>

---

From: Ray Hunter <[email-masked]>
Date: Wed, 20 Mar 2013 12:27:20 +0100

>> If it says "Use a ULA prefix!", I would certainly object to BCP.
Agreed. Let's see how the draft evolves.
> The homenet arch (which is Informational) is recommending use of ULAs. There are real use cases already identified there, particularly with constrained devices; one of the arch text authors is I be…
Yes, and I commented on homenet that I thought this recommendation was
still controversial.

We should have a proper discussion, and not just use the fact it's
currently included in one draft to justify including it in another.
> The other arguments made include disconnected operation,
I have no problem with this. But that is using ULA more like
self-assigned addresses, which don't communicate with the Public Internet.
>  and internal connection persistence through ISP-traiggered renumbering events.
Has this been operationally proven?

Also, having witnessed problems/issues with highly mobile nodes crossing
between "inside" and "outside" on corporate networks (admittedly mainly
with IPv4), I'd like to know of real world IPv6 experience with split
horizon operation and highly mobile devices using ULA.

I know the theory, but do we know how all of these items are cached and
used in practise?

I know various bits of Windows and certain applications do an awful lot
of work under the hood to implement "Network Location Awareness" e.g.
whether they are "on net" or "off net", so that they know what NAT
traversal/proxies/ firewall rules/ spilt DNS etc. to use: including
detecting whether the node is a member of a AD domain, whether it is
using RFC1918 addresses, whether certain FQDN's can be resolved, whether
certain web sites can be reached, if it is connected to specific SSID
name, downloading proxy pac files, printer reachability, address of DHCP
server, gateway address......

(Incorrect) use of ULA might just make all of that gubbins necessary for
IPv6 in every OS or application, which would be a shame.

If you only ever use GUA, you don't need to make any choice.

> A challenge is dealing with multiple internal routers that may generate a /48 ULA, including cases where such devices are initially not connected and are then joined/merged.  In such cases devices…
One of the use cases Fred gave was two cooperating corporations with a
"backdoor link" using disjoint /48 ULAs, which would also require policy
changes from the default on both sets of hosts to prefer the other
corporations' /48 ULA over their GUA.

We don't yet have a fully standardised mechanism to distribute address
selection policy, never mind one that has been widely implemented with
extensive operational experience. [I know
draft-ietf-6man-addr-select-opt-08]

regards
RayH

---

From: Arturo Servin <[email-masked]>
Date: Wed, 20 Mar 2013 08:49:00 -0300

> However, an informational description of appropriate deployment scenarios

	I agree, but we have so little experience with ULA deployment that
these recommendations are far for being a BCP. In reality they are like
"we think that this is the best way to use ULAs, but we don't really
know because we haven't use it a lot."

/as

---

From: Tim Chown <[email-masked]>
Date: Wed, 20 Mar 2013 12:08:49 +0000

On 14 Mar 2013, at 23:35, Doug Barton <[email-masked]> wrote:

> Of course, but that's not a technical difference between ULA and 1918. As I pointed out in my reply to Victor, the distinction is that it's less likely to happen with ULA, which is worth noting of course.

Well, with ULAs you have *significantly* less chance of overlap. But without ULA-C, which died a death, there is a possibility, however small.

What worries me is that in non-zeroconf environments, or those where manual override is possible, administrators will use fc00::/48, as it's easier to type/remember.  Then you're back on a par with using 10.0.0.0/8.

Tim

---

From: Tim Chown <[email-masked]>
Date: Wed, 20 Mar 2013 12:22:26 +0000

> currently included in one draft to justify including it in another.

The 'rough consensus' at the moment, as described at Orlando, is to leave it in. If you feel it is contentious, perhaps start a new thread on the homenet list explaining why.  

> self-assigned addresses, which don't communicate with the Public Internet.

Well, that's what they are? There's no other address space available for such contexts, is there?

> Has this been operationally proven?

It's worked here when we've tried it, but it would be interesting to hear of any issues arising for anyone who has used it in real anger.

> I know the theory, but do we know how all of these items are cached and

I think this is why it is important that nodes both understand what site they're in (which as someone else pointed out may be linked to the 'provisioning domain' discussion of Orlando) and also which prefixes (ULA or otherwise) are associated to those domains. Otherwise yes, you could be selecting a ULA source for a remote, non-routable ULA destination.

> server, gateway address...…

IPv6 should remove the 'behind NAT' to 'behind NAT' home to home issues by using GUAs for such home to come connectivity.

> IPv6 in every OS or application, which would be a shame.

I think you have valid concerns, but the best way to discuss these is via a draft/text where they are enumerated, be that draft-liu-v6ops-ula-usage-analysis, or a homenet-specific new draft.  The existing draft doesn't really tackle these concerns.

> If you only ever use GUA, you don't need to make any choice.

Well, then you have different concerns about disconnected operation.

> corporations' /48 ULA over their GUA.

That may well be a broader issue.  My particular interest is in trying to edit and identify consensus for homenet.

> draft-ietf-6man-addr-select-opt-08]

True, and that method is designed for managed enterprises, not homenets.  

Tim

---

From: Owen DeLong <[email-masked]>
Date: Wed, 20 Mar 2013 08:05:43 -0500

+1

Well said, Arturo. Personally, the more this discussion evolves, the more
convinced I become that ULA is an ugly can of worms that is best when left
unopened.

Unfortunately, that ship has sailed.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Wed, 20 Mar 2013 08:03:22 -0500

Currently, there is no defined use of L-bit = 0 to the best of my knowledge.

I believe that fc00::/8 sits "idle" as the IETF failed to designate a registry
structure and the ULA-registered draft expired without consensus.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Wed, 20 Mar 2013 08:18:13 -0500

> The 'rough consensus' at the moment, as described at Orlando, is to leave it in. If you feel it is contentious, perhaps start a new thread on the homenet list explaining why.  

I'm not on home net, but I think it's a profoundly bad idea as well.

> Well, that's what they are? There's no other address space available for such contexts, is there?

Yes, GUA is a perfectly fine choice of addressing for such contexts and ULA offers no advantage over GUA other than avoiding RIR interactions/fees.

> It's worked here when we've tried it, but it would be interesting to hear of any issues arising for anyone who has used it in real anger.

Please do not carry forward the problems of NAT traversal into IPv6.

Some of us would like to see actual application innovation occur.

Some of us are tired of paying the "NAT Tax" for everyone else that isn't using globally unique numbering.

> I think this is why it is important that nodes both understand what site they're in (which as someone else pointed out may be linked to the 'provisioning domain' discussion of Orlando) and also whi…

This is asking an awful lot of nodes compared to what they are capable of in this realm today. Doing so in a manner that does not break existing implementations seems to be a rather daunting challenge at best.

> IPv6 should remove the 'behind NAT' to 'behind NAT' home to home issues by using GUAs for such home to come connectivity.

Agreed, but when you throw ULAs into the mix, especially if you throw them in as a "BCP" or recommended way to do things, you either create a bunch of new node requirements for addressing awareness and source/destination address selection, or, you severely complicate other areas and create the need for header rewriting by routers. Both of these possibilities are somewhere between a small step and a giant leap into the "down that path lies madness" zone IMHO.

> I think you have valid concerns, but the best way to discuss these is via a draft/text where they are enumerated, be that draft-liu-v6ops-ula-usage-analysis, or a homenet-specific new draft.  The e…

Yes, but these concerns are a valid reason to delay, modify, or abandon the existing draft.

It is not valid to say "This draft doesn't address those concerns, go write another draft" and then expect this draft to be adopted in spite of the concerns.

> Well, then you have different concerns about disconnected operation.

How so? GUA is a perfectly fine alternative for disconnected operation.

> That may well be a broader issue.  My particular interest is in trying to edit and identify consensus for home net.

My concern is making sure we don't break the internet by making NAT a common feature in IPv6.

I don't care whether it's homenet, enterprisenet, or backbonenet… If we do stupid address tricks that naturally lead to NAT being a convenient solution, we will recreate a number of problems that IPv6 was intended to solve and regress  the internet in a very bad way.

Owen

---

From: Arturo Servin <[email-masked]>
Date: Wed, 20 Mar 2013 10:30:05 -0300

They have some real uses but in very specific scenarios with specif
constrains like in homenet and DC with IPv6:

http://tools.ietf.org/html/draft-ietf-homenet-arch-07#section-2.4

http://tools.ietf.org/html/draft-lopez-v6ops-dc-ipv6-04#section-3.1

	And even there, it may be questionable.

/as

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 20 Mar 2013 15:22:58 +0100

Le 20/03/2013 14:18, Owen DeLong a écrit :
[...]
> How so? GUA is a perfectly fine alternative for disconnected

YEs and no.

GUA (Global Unicast Addresses) is a good temptation to be used in all
cases, even in disconnected operation.

But, one should consider the cases of re-connection of moving networks
at different places in the Internet, successively.

In these cases there may be a risk, because a GUA is valid only at one
topological place.  Moving elsewhere one should use a different GUA.

Should we allow two vehicles which have GUAs and meet each other to talk
to each other directly?  At that point would topological correctness
still be respected with respect to ingress filtering? (what if one of
the vehicles _is_ connected to the Internet).

(I am not saying that ULA completely solves this, but that the use of
GUA in disconnected operation may be a less tempting invitation).

Alex

>
>>>> A challenge is dealing with multiple internal routers that may
>>>> generate a /48 ULA, including cases where such devices are
>>>> initially not connected and are then joined/merged.  In such
>>>> cases devices in the homenet need to be aware of which ULA
>>>> prefixes are internal to the home, and thus that should be
>>>> preferred over GUAs for address selection.
>>>>
>>>> Tim
>>> One of the use cases Fred gave was two cooperating corporations
>>> with a "backdoor link" using disjoint /48 ULAs, which would also
>>> require policy changes from the default on both sets of hosts to
>>> prefer the other corporations' /48 ULA over their GUA.
>>
>> That may well be a broader issue.  My particular interest is in
>> trying to edit and identify consensus for home net.
>
> I don't care whether it's homenet, enterprisenet, or backbonenet… If
> we do stupid address tricks that naturally lead to NAT being a
> convenient solution, we will recreate a number of problems that IPv6
> was intended to solve and regress  the internet in a very bad way.
>
> Owen
>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>
>

---

From: Tim Chown <[email-masked]>
Date: Wed, 20 Mar 2013 14:25:24 +0000

> I'm not on home net, but I think it's a profoundly bad idea as well.

I suggest you contribute specific reasons to either this analysis draft (which seems a bit short on that aspect at the moment, given it is an analysis text), or write a new focused draft on the issues.  That would be very helpful.

> Yes, GUA is a perfectly fine choice of addressing for such contexts and ULA offers no advantage over GUA other than avoiding RIR interactions/fees.

So how do I get a GUA if I have no relationship with an ISP?

What should those installing constrained networks do, when devices may only have an address configured on installation?

> Some of us are tired of paying the "NAT Tax" for everyone else that isn't using globally unique numbering.

ULAs in homenet have nothing to do with NAT.

> This is asking an awful lot of nodes compared to what they are capable of in this realm today. Doing so in a manner that does not break existing implementations seems to be a rather daunting challe…

True, but I think we'll see ULAs in use in homenets regardless, due to the LLN type scenarios (see above).

> Agreed, but when you throw ULAs into the mix, especially if you throw them in as a "BCP" or recommended way to do things, you either create a bunch of new node requirements for addressing awareness…

So there needs to be a text that describes very clearly how use of ULAs can be avoided, given the types of issues mentioned above. Now would be a very timely point to write that up.

> It is not valid to say "This draft doesn't address those concerns, go write another draft" and then expect this draft to be adopted in spite of the concerns.

Well, let me say that I would like to see your, and Ray's concerned properly documented, where they can be discussion points rather than comments buried in a very long email thread.  Where that happens, I personally don't mind.  Given the current ula-usage-analysis text is there, adding counterpoints in what is, after all, called an analysis draft, would imo be welcome.

> How so? GUA is a perfectly fine alternative for disconnected operation.

How is (non) expiry of the prefix handled, etc?

> I don't care whether it's homenet, enterprisenet, or backbonenet… If we do stupid address tricks that naturally lead to NAT being a convenient solution, we will recreate a number of problems that I…

Again, homenet use of ULAs has nothing to do with NAT. The complexity, I think, is ensuring devices understand which ULA prefix(es) are local to the homenet.   GUAs are used for external communications.

Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Mar 2013 15:22:58 +0000

On 20/03/2013 13:18, Owen DeLong wrote:
...
> Yes, GUA is a perfectly fine choice of addressing for such contexts and ULA offers no advantage over GUA other than avoiding RIR interactions/fees.

I think that may prove to be a significant advantage when applied, say, to 5 billion
home networks that don't want to be beholden to an incumbent telco. But that is better
argued in homenet.

   Brian

---

From: Tim Chown <[email-masked]>
Date: Wed, 20 Mar 2013 15:26:52 +0000

On 20 Mar 2013, at 15:22, Brian E Carpenter <[email-masked]> wrote
> home networks that don't want to be beholden to an incumbent telco. But that is better

The homenet arch text states that it assumes homenets would never receive PI, so the RIR interactions/fees are purely to the homenet provider/ISP, as part of its own allocation.

ULA-C would be a different thing. But is currently in cryo-freeze and the key thrown away.

Tim

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 20 Mar 2013 08:54:54 -0700

On Wed, Mar 20, 2013 at 5:08 AM, Tim Chown <[email-masked]> wrote:

> What worries me is that in non-zeroconf environments, or those where
> manual override is possible, administrators will use fc00::/48, as it's
> easier to type/remember.  Then you're back on a par with using 10.0.0.0/8.
>

But the unfortunate truth is that, really, ULA is no different from 10/8.

I see only one difference between ULA and 10/8. That difference is *not*
that ULAs are unique, because as you correctly note above, there is no hope
of them actually being unique in the real world. The difference is that in
IPv6 you are expected to use multiple addresses at the same time, and that
you can use ULA *and* something else.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 20 Mar 2013 17:28:06 +0100 (CET)

On Wed, 20 Mar 2013, Lorenzo Colitti wrote:

> IPv6 you are expected to use multiple addresses at the same time, and 
> that you can use ULA *and* something else.

It is my understanding that if a host sees RAs with A bit set, and the 
on-link prefix is ULA, it will install a default route towards the 
RA-announcing router.

This for me makes ULA a no-go. I never want to use ULA to access GUA 
address space. Since the address and routing tables weren't logically 
separated from initial IPv6 design (I would like a separate routing table 
per IPv6 address), I don't see how the deployment case of having LL+ULA 
for IPv6 and whatever for IPv4 doesn't negatively impact the users 
Internet experience?

What am I missing? RFC5220 2.2.2 talks about this and changing the policy 
table, but I don't see how this is done in hosts today without manual user 
intervention? Shouldn't draft-liu-v6ops-ula-usage-analysis analyse 
LL+ULA+IPv4 usage for Internet connectivity?

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Mar 2013 16:46:15 +0000

> on-link prefix is ULA, it will install a default route towards the

If there's only one prefix on a LAN and that is a ULA prefix, you
can't reach the outside world anyway (unless there's an NPTv6 box),
so what's the problem?

If there *is* an NPTv6 box, you want a default route towards it,
so what's the problem?

If there is also a GUA prefix, that's the one you want the default route
for, and source address selection should take care of the rest, so
what's the problem?

   Brian

> separated from initial IPv6 design (I would like a separate routing
> table per IPv6 address), I don't see how the deployment case of having
> LL+ULA for IPv6 and whatever for IPv4 doesn't negatively impact the
> users Internet experience?
> 
> What am I missing? RFC5220 2.2.2 talks about this and changing the
> policy table, but I don't see how this is done in hosts today without
> manual user intervention? Shouldn't draft-liu-v6ops-ula-usage-analysis
> analyse LL+ULA+IPv4 usage for Internet connectivity?
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 20 Mar 2013 09:49:43 -0700

> can't reach the outside world anyway (unless there's an NPTv6 box),

OIne problem is that hosts will prefer non-working ULA over working IPv4.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 20 Mar 2013 18:00:29 +0100 (CET)

> can't reach the outside world anyway (unless there's an NPTv6 box),

I can reach the outside world with my IPv4 address just fine. I can't 
reach it with my IPv6 ULA address.

So now the gateway device needs to send ICMP unreachables for every IPv6 
connection towards the Internet I try. I find this problematic.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 20 Mar 2013 18:03:30 +0100

Le 20/03/2013 16:54, Lorenzo Colitti a écrit :
> On Wed, Mar 20, 2013 at 5:08 AM, Tim Chown <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>  manual override is possible, administrators will use fc00::/48, as
> it's easier to type/remember.

But not what the RFC says - it's wrong sysadmin.

> Then you're back on a par with using 10.0.0.0/8 <http://10.0.0.0/8>.
>
>
> I see only one difference between ULA and 10/8. That difference is
> *not* that ULAs are unique, because as you correctly note above,
> there is no hope of them actually being unique in the real world.

So, Lorenzo, I wouldnt qualify it as strongly.  There _is_ much hope.

Anyone who tried to configure ULAs according to that RFC knows that
there is some  level of uniqueness guaranteed.

(if one just tries to just try quickly ifconfig add fd::1/64 then
it's probably not according to the RFC, which would want more digits there.)

> The difference is that in IPv6 you are expected to use multiple
> addresses at the same time, and that you can use ULA *and* something
> else.

I agree.

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Mar 2013 17:22:02 +0000

> reach it with my IPv6 ULA address.

Right, so you want (ULA source and non-ULA destination) to be lower
pref than (IPv4 source and IPv4 destination). That sounds algorithmic.

    Brian

---

From: Mark Smith <[email-masked]>
Date: Wed, 20 Mar 2013 11:46:34 -0700 (PDT)

----- Original Message -----
> From: Tim Chown <[email-masked]>
> To: [email-masked]
> Cc: 
> Sent: Wednesday, 20 March 2013 11:08 PM
>>>  If both sites are using 10.0.0.0/8 in an overlapping manner, then 
> connecting them via routers does not yield goodness.
>> 
> As I pointed out in my reply to Victor, the distinction is that it's less 
> likely to happen with ULA, which is worth noting of course.
> 
> Well, with ULAs you have *significantly* less chance of overlap. But without 
> ULA-C, which died a death, there is a possibility, however small.
> 
> What worries me is that in non-zeroconf environments, or those where manual 
> override is possible, administrators will use fc00::/48, as it's easier to 
> type/remember.  Then you're back on a par with using 10.0.0.0/8.
> 

The Fritzbox CPE a few years back made a failed attempt at using ULAs. They did exactly that i.e. no random ID, and attempted to *swap* the ULA for the GUA when the GUA disappeared due to the WAN link going down and vice versa. The thing I couldn't work out was how they product developers had read enough to know of ULAs, but didn't read enough to implement them properly. Probably just another example of IPv6 being thought of as nothing more than IPv4 with bigger addresses. Unfortunately they were ignoring my bug reports, unlike a number of other CPE vendors I was dealing with at the time.

It seems to me that one of the ways to make things more robust is to reduce external dependencies. Using ULAs for internal addressing and for internal access, and only using GUAs for external global Internet access, is making your internal access robust against external GUA related events (e.g. your ISP going away, or your GUA prefix expiring, or you haven't got an ISP yet).

Over the last few years, CPEs have gained features beyond just providing global Internet connectivity. The Fritzbox example above can also act as a NAS if you plug a USB disk into it, a network print server for a USB printer, and a SIP DECT gateway. Given the expense of these higher end CPEs, end users would be quite reasonably frustrated if they can't use some of these other non-global Internet features while they don't have an active GUA from an ISP. For example, I wouldn't be happy if I was watching a movie being streamed from the NAS in this CPE and it then stopped because my Internet connection had gone down and my GUA had expired.

RFC6204 specifies ULAs for internal addressing for these reasons.

Regards,
Mark.

---

From: Philipp Kern <[email-masked]>
Date: Wed, 20 Mar 2013 19:51:48 +0100

On Wed, Mar 20, 2013 at 11:46:34AM -0700, Mark Smith wrote:
> The Fritzbox CPE a few years back made a failed attempt at using ULAs. They
> did exactly that i.e. no random ID, and attempted to *swap* the ULA for the
> GUA when the GUA disappeared due to the WAN link going down and vice
> versa.

I need to check it again but that's exactly what a DTAG CPE (Speedport) in
Germany does. You can turn on ULAs through the web interface and don't even get
to pick the bits. My personal guess is that DTAG fixed it on all but I don't
have multiple devices to test.

Kind regards
Philipp Kern

---

From: Mark Smith <[email-masked]>
Date: Wed, 20 Mar 2013 12:22:18 -0700 (PDT)

>To: Tim Chown <[email-masked]> 
>Cc: "[email-masked] WG" <[email-masked]> 
>Sent: Thursday, 21 March 2013 2:54 AM

I disagree. site-locals were no different from 10/8. ULAs don't suffer from the problems that site-locals (and RFC1918) do that are detailed in RFC3879. 

You could argue that people will be lazy and not use a globally unique ID. Unfortunately we can't legislate against not following the specifications (a.k.a., being lazy). In this case, if they join their Non-Unique Unique Local Addressed network with another one that has also not followed the specifications, then the renumbering or NAT/NPT pain will be theirs and their partner's alone. 

>
>
>
>
>I see only one difference between ULA and 10/8. That difference is *not* that ULAs are unique, because as you correctly note above, there is no hope of them actually being unique in the real world. The difference is that in IPv6 you are expected to use multiple addresses at the same time, and that you can use ULA *and* something else.
>_______________

Why is there no hope? You're effectively saying that the ULA specifications won't ever be followed correctly, rather than far more often than not. Couldn't the same be said about any and all specifications? Why would people follow nearly all specifications correctly, with the ULA specification being the special case where they won't?

---

From: Mark Smith <[email-masked]>
Date: Wed, 20 Mar 2013 12:39:37 -0700 (PDT)

----- Original Message -----
> From: Brian E Carpenter <[email-masked]>
> To: Mikael Abrahamsson <[email-masked]>
> Sent: Thursday, 21 March 2013 4:22 AM

And these are the sorts of scenarios which eventuated in Happy Eyeballs (RFC6555).

Fred has written up a draft which clarifies that the Happy Eyeballs wasn't really meant to be just restricted to HTTP applications, and was intended to be a more general approach for multihomed hosts (with multihoming also including a single interface but dual stacked host).

"Happier Eyeballs"
https://www.ietf.org/id/draft-baker-happier-eyeballs-00.txt

Regards,
Mark.

---

From: Owen DeLong <[email-masked]>
Date: Wed, 20 Mar 2013 14:44:57 -0500

Sent from my iPad

> can't reach the outside world anyway (unless there's an NPTv6 box),

The problem is that you can reach the outside world via IPv4.

While I think this is an inherently stupid way to deploy IPv6 within an organization (IPv6 only good within the organization and IPv4 for outside (whether or not IPv4 is usable inside)), the reality is that it is a technically valid scenario and ULA6+IPv4 without GUA6 == broken user experiences.

> If there *is* an NPTv6 box, you want a default route towards it,

If there is NOT an NPTv6 box and you have valid IPv4 connectivity...

> for, and source address selection should take care of the rest, so

The IF pretty much covers it. IF there is no GUA prefix and there is a GUA4
address or NAT44 based connectivity...

The internet is a complex place.

Owen

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 20 Mar 2013 20:47:02 +0100 (CET)

> https://www.ietf.org/id/draft-baker-happier-eyeballs-00.txt

I'd be happy if my customers are using Windows 7 and IE9. If ULAs cause a 
problem for this setup, I'm hesitant to deploy ULAs.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 20 Mar 2013 20:49:12 +0100 (CET)

On Wed, 20 Mar 2013, Owen DeLong wrote:

> The IF pretty much covers it. IF there is no GUA prefix and there is a 
> GUA4 address or NAT44 based connectivity...
>

It's not even complex. I see recommendations for CPEs to start announcing 
ULAs even if they have no GUA, or that ULAs should be announced even if 
the GUA prefix goes away. This will lead to broken connectivty as you say, 
bad user experience, and I don't like this recommendation.

---

From: Owen DeLong <[email-masked]>
Date: Wed, 20 Mar 2013 15:03:17 -0500

Sent from my iPad

> But not what the RFC says - it's wrong sysadmin.

Which matters here in the ivory tower, but makes no difference in the real world.

> So, Lorenzo, I wouldnt qualify it as strongly.  There _is_ much hope.

Only among overly optimistic idealists.

> there is some  level of uniqueness guaranteed.

No, there is no level of uniqueness guaranteed. There is a statistically high probability of uniqueness for those who deploy ULA according to the RFC. Even there, there is no guarantee of any level of uniqueness, just a strong probability. However, the probability that the majority of administrators will even read the ULA RFC (how many people do you think have actually read RFC-1918 vs. the number that have deployed 10/8 or any other RFC-1918 address? I'll give you a hint... Ask a bunch of administrators which of the following are RFC-1918 addresses. If it's not an open book test, I bet the results surprise you.
		172.16.5.3		Everyone will probably get this right.
		172.30.19.6		About half will get this wrong.
		172.32.99.7		The other half will get this wrong.
		172.80.15.7		About half of the ones that got the previous question wrong will
						also get this one wrong.

> it's probably not according to the RFC, which would want more digits there.)

fd::1/64 isn't even ULA, but I wouldn't put it past administrators to think it is.
fd00::1/64, OTOH, will probably be the most common ULA gateway address.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Wed, 20 Mar 2013 15:04:08 -0500

> pref than (IPv4 source and IPv4 destination). That sounds algorithmic.

Sure, but it contradicts the algorithm currently deployed in a very large base of installed systems.

Owen

---

From: Mark Smith <[email-masked]>
Date: Wed, 20 Mar 2013 13:07:22 -0700 (PDT)

----- Original Message -----
> From: Mikael Abrahamsson <[email-masked]>
> To: "[email-masked] WG" <[email-masked]>
> Cc: 
> Sent: Thursday, 21 March 2013 6:47 AM
>>  Fred has written up a draft which clarifies that the Happy Eyeballs 
> wasn't really meant to be just restricted to HTTP applications, and was 
> intended to be a more general approach for multihomed hosts (with multihoming 
> also including a single interface but dual stacked host).
>> 
>>  "Happier Eyeballs"

So you're a service provider, your ULA addressing domain would have it's boundary between your network and your customers networks, and your transit and peers i.e. on your BNG/BRAS/CMTSs, border routers etc. Your customers' ULA addressing domain boundary would occur on their CPE, at the boundary of their network. In other words, your customers' internal networks are not part of your ULA addressing domain - they have their own ULA addressing domain. If the customer operates the CPE, you wouldn't know and shouldn't care about whether they use ULA addressing internally or not. If you operate the CPE, you might care, but only just because it is a configuration parameter of the CPE.

There would be no ULA addresses on the link between you and your customer. You would drop traffic with ULA sources and/or destinations received from your customers as per standard BCP38/martian/bogon filtering practices.

So you don't have to deploy ULAs inside your service provider network if you don't want to, although I think there are operational advantages to having internal infrastructure/OAM etc. addressing that is independent of external RIRs GUA addressing. Your customers would have benefits of ULA addressing internally because their internal IPv6 network will still work if their Internet connection goes down.

Regards,
Mark.

---

From: Ray Hunter <[email-masked]>
Date: Wed, 20 Mar 2013 21:10:10 +0100

> pref than (IPv4 source and IPv4 destination). That sounds algorithmic.
Correct.

But it's a no win situation on the default source address selection
rules, as I pointed out when we were discussing RFC6724.

As IPv6 is introduced we might have stand alone islands of IPv6,
discontiguous from the global Internet.
As IPv4 dies out, we might eventually have islands of legacy IPv4
devices disconnected from the global Internet.

There's no reliable way to signal to an end node whether
i) IPv4 RFC1918 is a stand alone pool disconnected from the Internet =
local /8 /16 or /24 route only, or RFC 1918 + NAPT = default route to
the Internet
ii) IPv6 ULA is a stand alone pool disconnected from the Internet =
local /48 route only, or multiple ULA's on one site = multiple /48
routes, or ULA + NPTv6 = default route to the Internet.

AFAIK We have the following options
1) all end nodes must support draft-ietf-6man-addr-select-opt-08 (which
is not yet an RFC, never mind widely supported)
2) Mikael's idea for a PIO to be associated with a specific route,
rather than just a global default route (not even an ID yet, although
definitely interesting)
3) every app having to support RFC6555 Happy Eyeballs [and yet many
current apps can't even properly handle multiple A records in a reply]
4) weak linkage of default route next hop selection with PIO, from rule
5.5 of RFC6724 [fixes selection between 2 IPv6 GUA, although that does
not address isolated IPv6 ULA v IPv4 NAPT]
5) OS specific kludges, like Windows "Network Location Awareness"
6) manual admin config

I don't find that very satisfactory. Unless of course someone else has a
better option I've missed.

I think this will be a problem for draft-ietf-homenet-arch-07 Section
3.2.2.2 B: Two ISPs, Two CERs, Shared subnet Figure 2

I think homenet is making an implicit assumption that ULA implies a
stand alone /48 network, that is disconnected from everything else, so
ULA should only be used for local communication as per rfc4193 section 4.6.

Although that apparently isn't the only deployment scenario for ULA;
such as the suggestion to use them for private communication between 2
enterprises (but not via public Internet), or ULA + NPTv6, or even ULA +
NAPT.

I think homenet is probably also making an implicit assumption that IPv4
RFC 1918 => IPv4 + NAPT

>> connection towards the Internet I try. I find this problematic.
Expect in the scenario where multiple ULA's are used for backdoor
connections between two (or more) private ULA networks, which also
distribute GUA PA addresses per site to access the global Internet [I've
seen that suggested as a deployment model for geographically spread
enterprises who wish to have multiple local Internet breakouts, but do
not want to use PI space]

So that's also problematic to just always send an ICMP unreachable for
non local /48 ULA.

You have to make that decision on sending ICMP unreachable in
combination with knowledge of the site topology, and what interfaces are
"borders" to the Public Internet.

regards,
RayH

---

From: Owen DeLong <[email-masked]>
Date: Wed, 20 Mar 2013 15:10:24 -0500

> Why is there no hope? You're effectively saying that the ULA specifications won't ever be followed correctly, rather than far more often than not. Couldn't the same be said about any and all specif…

ULA is not the lone specification. There are lots of specifications that get ignored.

However, there is an important distinction to consider here. Most specifications are to be understood and implemented by protocol developers putting those implementations into products. In the case of ULA, you're now talking about the need for a site administrator to follow the specification, In my experience, there is a very wide range in terms of experience, capability, and motivation within this group, but it is overwhelmingly weighted towards the low end (unmotivated, not very experienced, and unlikely to even read an RFC vs. take their buddy's advice that "fd00::/8 for IPv6 works just like 10/8 for IPv4".

Owen

---

From: Mark Smith <[email-masked]>
Date: Wed, 20 Mar 2013 13:23:48 -0700 (PDT)

----- Original Message -----
> To: Owen DeLong <[email-masked]>
> Sent: Thursday, 21 March 2013 6:49 AM
> ULAs even if they have no GUA, or that ULAs should be announced even if the GUA 
> prefix goes away. This will lead to broken connectivty as you say, bad user 
> experience, and I don't like this recommendation.
> 

It won't lead to broken connectivity. ULAs are now preferred over GUAs in RFC6724, and that only really matters is when you are given a choice of both a GUA and a ULA. The only devices for which ULA and GUA AAAA records may be received will be internal devices, and that could even be made selective by having the DNS resolvers only hand ULA AAAA records to internal clients if necessary. Internet devices should only have GUA AAAAs.

The local networks will usually be more stable and reliable than the global network, mainly because a local single party controls and operates the local network, where as the global network (i.e. the Internet) is both much, much larger, and operated by many different parties. Having both a local and global address space, and preferring the local addresses over the global ones when both are available, further makes the local network more reliable and independent of the state of the global network.

> -- Mikael Abrahamsson    email: [email-masked]

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 20 Mar 2013 20:41:12 +0000

> While some of us have been using them in various contexts, unless we hear of widescale, significant deployments, it's difficult to argue for BCP.

</chair>

I agree, and yet I scratch my head. How wide-scale can one possibly deploy a prefix that is only usable within a domain? How likely are you to hear about it outside of that domain?

If there were a single statement that I might expect a BCP to make about ULAs, it would be along the lines of a comment I made a week or so ago: a ULA is by definition a prefix that is never advertised outside a given domain, and is used within that domain by agreement of those networked by the domain. The purpose for which they do so is more or less irrelevant, although examples of such use (usually with RFC 1918 space) in existing networks might point in reasonable directions. 

The value of a prefix that is not advertised outside a domain tends to be in hiding something, and making it unreachable, from networks outside the domain. The b2b example in the draft has them hiding the actual identities of equipment in companies that are different but have operating agreements for specific purposes, for example, and using them to address equipment that would otherwise need to be filtered at a firewall eliminates the firewall rule. I hear a lot of "we don't need no stinking firewalls"; OK, if you want to get rid of them, provide an alternative that meets people's stated concerns.

If we can't make a statement along those lines, it seems like the other statement a BCP could make is "please don't deploy ULAs, ever, for any reason". I think we might have an equally hard time coming to consensus on that; they were created for a reason, and the reason wasn't NATs.

I think the primary issue that people are really raising here is "please don't NAT". IMHO, there are already NAT66 products out there, and I have customers chomping at the bit to deploy them. I agree that stateful NAT was at best an evil we chose to live with. I'm not sure that complaining about them will make them go away. But in a world without NATs, there are still valid uses for a prefix that is advertised only within a bounded domain. I do wonder why we are so bent on tossing the baby while we complain about the bathwater.

---

From: Owen DeLong <[email-masked]>
Date: Wed, 20 Mar 2013 15:49:12 -0500

Sent from my iPad

> at different places in the Internet, successively.

How is GUA not an ideal candidate for this? Seems to me that is the poster child for PI GUA.

> topological place.  Moving elsewhere one should use a different GUA.

No, a GUA can be portable or non-portable.

> the vehicles _is_ connected to the Internet).

Seems to me that this is an ideal application for either BGP or MIP, depending on the various factors involved in the nature of the communication between those vehicles and/or their other topological relationships. Perhaps even a combination of BGP and MIP.

> GUA in disconnected operation may be a less tempting invitation).

ULA does not provide any benefits over GUA in this context.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Wed, 20 Mar 2013 15:59:50 -0500

Sent from my iPad

> The homenet arch text states that it assumes homenets would never receive PI, so the RIR interactions/fees are purely to the homenet provider/ISP, as part of its own allocation.

Too late... I already know of at least a few homenets that are running with IPv6 PI.

> ULA-C would be a different thing. But is currently in cryo-freeze and the key thrown away.

That is NOT a bad thing IMHO.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Wed, 20 Mar 2013 15:58:51 -0500

Sent from my iPad

> home networks that don't want to be beholden to an incumbent telco. But that is better

I'm not sure about that. I think, actually, if those 5 billion homes (an interesting number for a planet with 7 billion people where the average household is 3.8 people, btw) were to go to the RIRs, the RIRs would be able to engage in a sufficient fee reduction as to make that relatively unimportant.

Currently, for example, ARIN would cost $100/year for the user to get an IPv6 /48 block. This is based on having a few thousand end-user resources registered. If that were to become millions of end-user resources, the cost would probably drop to something closer to $20/year.

Remember, the RIRs are not for profit entities. Larger quantities of end-user registrations should directly equate to lower fees.

Owen

---

From: joel jaeggli <[email-masked]>
Date: Wed, 20 Mar 2013 16:36:25 -0700

> structure and the ULA-registered draft expired without consensus.
Did not choose to, and failed to are somewhat different implications 
event if the effective result is the same.

---

From: Owen DeLong <[email-masked]>
Date: Wed, 20 Mar 2013 19:17:37 -0500

On Mar 20, 2013, at 6:36 PM, joel jaeggli <[email-masked]> wrote:

> Did not choose to, and failed to are somewhat different implications event if the effective result is the same.

In what way?

Owen

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 21 Mar 2013 03:21:47 +0100 (CET)

On Wed, 20 Mar 2013, Mark Smith wrote:

> It won't lead to broken connectivity. ULAs are now preferred over GUAs 
> in RFC6724, and that only really matters is when you are given a choice 
> of both a GUA and a ULA. The only devices for which ULA and GUA AAAA 
> records may be received will be internal devices, and that could even be 
> made selective by having the DNS resolvers only hand ULA AAAA records to 
> internal clients if necessary. Internet devices should only have GUA 
> AAAAs.

You're missing the point.

Host has ULA+RFC 1918 IPv4. User enters www.google.com into their non-HE 
browser. Gets AAAA+A DNS reply. Will this user be a happy user?

I'm not worried about hosts that have ULA+GUA IPv6, I'm worried about the 
ones with only ULA IPv6 address and them trying to use this address to 
access IPv6 Internet instead of using their fully functional IPv4 address.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Mar 2013 13:47:24 +1100

> browser. Gets AAAA+A DNS reply. Will this user be a happy user?

If they are not using a ossified browsers yes.

It about time clients bit the bullet and fixed broken multi-homed
support.  This is a RFC 1123 requirement and in most cases not hard
to do.  Millions if not billions of dollars have been spent to work
around these broken applications in the last 20 years.  If browers,
which are much more complicated than the normal client, can add
good support for talking to multi-homed servers then just about any
client can.

Example C code is attached.  Just pick if you want select/poll/thread
based fast connections.

Working through the *BSD/Linux base distribution to add fast failover
would make a good Google Summer of Code project.

Mark

/*
 * Copyright (C) 2011  Internet Systems Consortium, Inc. ("ISC")
 *
 * Permission to use, copy, modify, and/or distribute this software for any
 * purpose with or without fee is hereby granted, provided that the above
 * copyright notice and this permission notice appear in all copies.
 *
 * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
 * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
 * AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
 * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
 * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
 * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 * PERFORMANCE OF THIS SOFTWARE.
 */

/*
 * Initial timeout between connection attempts.  The smaller this is the
 * more embryonic connection attempts that will be made.  On each subsequent
 * connection attempt the timeout will be halved leading to all connection
 * attempts being initiated within 2 * TIMEOUT ms.
 *
 * 100 ms will let most intra continent connections succeed without a
 *	  embryonic connection.
 * 400 ms well let most intercontinental connections succeed without a
 * 	  embryonic connection.
 */
#define TIMEOUT 100	/* 100 ms */

#define USE_THREADS 1
#define HAVE_POLL 1
#define TESTING 1

#if HAVE_POLL == 0 && TIMEOUT > 999
#define TIMEOUT 999	/* select() doesn't like tv_usec > 999999. */
#endif

#include <sys/types.h>
#include <sys/socket.h>
#if ! USE_THREADS
#if HAVE_POLL
#include <sys/poll.h>
#else
#include <sys/select.h>
#endif
#endif
#include <sys/time.h>

#include <netinet/in.h>

#include <assert.h>
#include <errno.h>
#if ! USE_THREADS
#include <fcntl.h>
#endif
#include <netdb.h>
#if USE_THREADS
#include <pthread.h>
#endif
#include <stdarg.h>
#include <stdbool.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

static void
print_trying(struct addrinfo *res, const char *trying) {
	char buf[sizeof("xxxx:xxxx:xxxx:xxxx:xxxx:125.123.123.123")] = "unknown family";

	switch (res->ai_family) {
	case AF_INET:
		inet_ntop(AF_INET, &((struct sockaddr_in *)res->ai_addr)->sin_addr,
			  buf, sizeof(buf));
		break;
	case AF_INET6:
		inet_ntop(AF_INET6, &((struct sockaddr_in6 *)res->ai_addr)->sin6_addr,
			  buf, sizeof(buf));
		break;
	}
	printf("%s %s\n", trying, buf);
}

#if USE_THREADS
struct common {
	pthread_mutex_t *mutex;
	pthread_cond_t *cond;
	int *count;
	int *fd;
};

struct state {
	struct addrinfo *addrinfo;
	struct common *common;
};

static void
fatal(char *format, ...) {
	va_list ap;

	va_start(ap, format);
	vfprintf(stderr, format, ap);
	va_end(ap);
	abort();
}

static void
connect_to_address_cleanup(void *arg) {
	int *fd = arg;

	if (*fd != -1)
		close(*fd);
}

static void *
connect_to_address(void *arg) {
	struct state *state = arg;
	struct addrinfo *addrinfo = state->addrinfo;
	struct common *common = state->common;
	int fd = -1, n;

	/* Ensure that fd is closed if we are canceled. */
	pthread_cleanup_push(connect_to_address_cleanup, &fd);
	fd = socket(addrinfo->ai_family, addrinfo->ai_socktype,
		    addrinfo->ai_protocol);
	if (fd < 0) {
		/*
		 * If AI_ADDRCONFIG is not supported we will get EAFNOSUPPORT
		 * returned.  Silently ignore it.
		 */
		if (errno != EAFNOSUPPORT)
			perror("socket");
	} else if (connect(fd, addrinfo->ai_addr, addrinfo->ai_addrlen) == -1) {
		perror("connect");
		close(fd);
		fd = -1;
	} 
	print_trying(state->addrinfo, "connected");
	/* If we get here we want the rest of the thread to complete. */
	n = pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL);
	if (n != 0)
		fatal("pthread_setcancelstate: %s", strerror(n));
	n = pthread_mutex_lock(common->mutex);
	if (n != 0)
		fatal("pthread_mutex_lock: %s", strerror(n));
	if (fd != -1 && *common->fd == -1) {
		/* Record success. */
		*common->fd = fd;
		fd = -1;
	}
	*common->count -= 1;
	n = pthread_mutex_unlock(common->mutex);
	if (n != 0)
		fatal("pthread_mutex_unlock: %s", strerror(n));
	pthread_cleanup_pop(1);
	/* Signal that we are done. */
	n = pthread_cond_signal(common->cond);
	if (n != 0)
		fatal("pthread_cond_signal: %s", strerror(n));
	pthread_exit(NULL);
}

int
connect_to_host(struct addrinfo *res0) {
	struct addrinfo *res;
	int fd = -1, n, i, j, count;
	pthread_t *threads;
	struct state *state;
	int timeout = TIMEOUT * 1000;
	struct timespec timespec;
	pthread_cond_t cond;
	pthread_mutex_t mutex;
	struct common common;

	/*
	 * Work out how many possible descriptors we could use.
	 */
	for (res = res0, count = 0; res; res = res->ai_next)
		count++;
	threads = calloc(count, sizeof(*threads));
	state = calloc(count, sizeof(*state));
	if (threads == NULL || state == NULL) {
		perror("calloc");
		goto cleanup;
	}

	n = pthread_mutex_init(&mutex, NULL);
	if (n != 0) {
		fprintf(stderr, "pthread_mutex_init: %s", strerror(n));
		goto cleanup;
	}

	n = pthread_cond_init(&cond, NULL);
	if (n != 0) {
		fprintf(stderr, "pthread_cond_init: %s", strerror(n));
		goto cleanup_mutex;
	}

	common.fd = &fd;
	common.cond = &cond;
	common.count = &count;
	common.mutex = &mutex;

	/*
	 * fd and count are protected by mutex.
	 */
	for (res = res0, i = 0, count = 0; res; res = res->ai_next) {
		bool done;

		state[i].common = &common;
		state[i].addrinfo = res;
		
		n = pthread_create(&threads[i], NULL, connect_to_address,
				   &state[i]);
		if (n != 0)
			fprintf(stderr, "pthread_create: %s", strerror(n));
		else {
			i++;
			n = pthread_mutex_lock(&mutex);
			if (n != 0)
				fatal("pthread_mutex_lock: %s", strerror(n));
			count++;
			n = pthread_mutex_unlock(&mutex);
			if (n != 0)
				fatal("pthread_mutex_unlock: %s", strerror(n));
		}
		print_trying(res, "trying");
		done = false;
		do {
			n = pthread_mutex_lock(&mutex);
			if (n != 0)
				fatal("pthread_mutex_lock: %s", strerror(n));
			/* No outstanding threads? */
			if (count == 0) {
				/* Are we done? */
				if (fd != -1 || res->ai_next == NULL)
					done = true;
				n = pthread_mutex_unlock(&mutex);
				if (n != 0)
					fatal("pthread_mutex_unlock: %s",
					      strerror(n));
				break;
			}
			if (res->ai_next != NULL) {
				struct timeval tv;

				n = gettimeofday(&tv, NULL);
				if (n != 0)
					fatal("gettimeofday: %s\n",
					      strerror(errno));
				timespec.tv_sec = tv.tv_sec;
				timespec.tv_nsec = (tv.tv_usec + timeout) *
						   1000;
				while (timespec.tv_nsec >= 1000000000) {
					timespec.tv_nsec -= 1000000000;
					timespec.tv_sec += 1;
				}
				n = pthread_cond_timedwait(&cond, &mutex,
						           &timespec);
			} else
				n = pthread_cond_wait(&cond, &mutex);

			if (n == ETIMEDOUT)
				timeout >>= 1;
			else if (n != 0)
				fatal("pthread_cond_%swait: %s\n",
				      res->ai_next != NULL ? "timed" : "",
				      strerror(n));
			if (fd != -1 || (count == 0 && res->ai_next == NULL))
				done = true;
			n = pthread_mutex_unlock(&mutex);
			if (n != 0)
				fatal("pthread_mutex_unlock: %s", strerror(n));
		} while (!done && res->ai_next == NULL);
		if (done)
			break;
	}

	/* Shutdown and tidy up all the threads we started. */
	for (j = 0; j < i; j++) {
		n = pthread_cancel(threads[j]);
		if (n != 0 && n != ESRCH)
			fatal("pthread_cancel: %s\n", strerror(n));
		n = pthread_join(threads[j], NULL);
		if (n != 0)
			fatal("pthread_join: %s\n", strerror(n));
	}

	/* Cleanup the resources we used. */
	n = pthread_cond_destroy(&cond);
	if (n != 0)
		fatal("pthread_cond_destroy: %s", strerror(n));

 cleanup_mutex:
	n = pthread_mutex_destroy(&mutex);
	if (n != 0)
		fatal("pthread_mutex_destroy: %s", strerror(n));

 cleanup:
	/* Free everything. */
	if (threads) free(threads);
	if (state) free(state);

	return (fd);
}
#elif HAVE_POLL
int
connect_to_host(struct addrinfo *res0) {
	struct addrinfo *res, **info;
	int fd = -1, n, i, j, flags, count;
	struct pollfd *fds;
	int timeout = TIMEOUT;

	/*
	 * Work out how many possible descriptors we could use.
	 */
	for (res = res0, count = 0; res; res = res->ai_next)
		count++;
	fds = calloc(count, sizeof(*fds));
	info = calloc(count, sizeof(*info));
	if (fds == NULL || info == NULL) {
		perror("calloc");
		goto cleanup;
	}

	for (res = res0, i = 0, count = 0; res; res = res->ai_next) {
		print_trying(res);
		fd = socket(res->ai_family, res->ai_socktype, res->ai_protocol);
		if (fd == -1) {
			/*
			 * If AI_ADDRCONFIG is not supported we will get
			 * EAFNOSUPPORT returned.  Behave as if the address
			 * was not there.
			 */
			if (errno != EAFNOSUPPORT)
				perror("socket");
			else if (res->ai_next != NULL)
				continue;
		} else if ((flags = fcntl(fd, F_GETFL)) == -1) {
			perror("fcntl");
			close(fd);
		} else if (fcntl(fd, F_SETFL, flags | O_NONBLOCK) == -1) {
			perror("fcntl");
			close(fd);
		} else if (connect(fd, res->ai_addr, res->ai_addrlen) == -1) {
			if (errno != EINPROGRESS) {
				perror("connect");
				close(fd);
			} else {
				/*
				 * Record the information for this descriptor.
				 */
				info[i] = res;
				fds[i].fd = fd;
				fds[i].events = POLLERR | POLLHUP |
						POLLIN | POLLOUT;
				count++;
				i++;
			}
		} else  {
			/*
			 * We connected without blocking.
			 */
			goto done;
		}

		if (count == 0)
			continue;

		do {
			if (res->ai_next == NULL)
				timeout = -1;

			n = poll(fds, i, timeout);
			if (n == 0) {
				timeout >>= 1;
				break;
			}
			if (n < 0) {
				if (errno == EAGAIN || errno == EINTR)
					continue;
				perror("poll");
				fd = -1;
				goto done;
			}
			for (j = 0; j < i; j++) {
				if (fds[j].fd == -1 || fds[j].events == 0 ||
				    fds[j].revents == 0)
					continue;
				fd = fds[j].fd;
				if (fds[j].revents & POLLHUP ||
				    read(fd, NULL, 0) == -1) {
					close(fd);
					fds[j].fd = -1;
					fds[j].events = 0;
					info[j] = NULL;
					count--;
					continue;
				}
				/* Connect succeeded. */
				goto done;
			}
		} while (timeout == -1 && count != 0);
	}

	/* We failed to connect. */
	fd = -1;

 done:
	/* Close all other descriptors we have created. */
	for (j = 0; j < i; j++)
		if (fds[j].fd != fd && fds[j].fd != -1) {
			close(fds[j].fd);
		}

	if (fd != -1) {
		/* Restore default blocking behaviour.  */
		if ((flags = fcntl(fd, F_GETFL)) != -1) {
			flags &= ~O_NONBLOCK;
			if (fcntl(fd, F_SETFL, flags) == -1)
				perror("fcntl");
		} else
			perror("fcntl");
	}

 cleanup:
	/* Free everything. */
	if (fds != NULL) free(fds);
	if (info != NULL) free(info);

	return (fd);
}
#else
int
connect_to_host(struct addrinfo *res0) {
	struct addrinfo *res, **info;
	int fd = -1, n, i, j, flags, count, max = -1, *fds;
	struct timeval *timeout, timeout0 = { 0, TIMEOUT * 1000};
	fd_set fdset, wrset;

	/*
	 * Work out how many possible descriptors we could use.
	 */
	for (res = res0, count = 0; res; res = res->ai_next)
		count++;
	fds = calloc(count, sizeof(*fds));
	info = calloc(count, sizeof(*info));
	if (fds == NULL || info == NULL) {
		perror("calloc");
		goto cleanup;
	}
	FD_ZERO(&fdset);
	for (res = res0, i = 0, count = 0; res; res = res->ai_next) {
		print_trying(res);
		fd = socket(res->ai_family, res->ai_socktype, res->ai_protocol);
		if (fd == -1) {
			/*
			 * If AI_ADDRCONFIG is not supported we will get
			 * EAFNOSUPPORT returned.  Behave as if the address
			 * was not there.
			 */
			if (errno != EAFNOSUPPORT)
				perror("socket");
			else if (res->ai_next != NULL)
				continue;
		} else if (fd >= FD_SETSIZE) {
			close(fd);
		} else if ((flags = fcntl(fd, F_GETFL)) == -1) {
			perror("fcntl");
			close(fd);
		} else if (fcntl(fd, F_SETFL, flags | O_NONBLOCK) == -1) {
			perror("fcntl");
			close(fd);
		} else if (connect(fd, res->ai_addr, res->ai_addrlen) == -1) {
			if (errno != EINPROGRESS) {
				perror("connect");
				close(fd);
			} else {
				/*
				 * Record the information for this descriptor.
				 */
				info[i] = res;
				fds[i] = fd;
				FD_SET(fd, &fdset);
				if (max == -1 || fd > max)
					max = fd;
				count++;
				i++;
			}
		} else  {
			/*
			 * We connected without blocking.
			 */
			goto done;
		}

		if (count == 0)
			continue;

		assert(max != -1);
		do {
			if (res->ai_next != NULL)
				timeout = &timeout0;
			else
				timeout = NULL;

			/* The write bit is set on both success and failure. */
			wrset = fdset;
			n = select(max + 1, NULL, &wrset, NULL, timeout);
			if (n == 0) {
				timeout0.tv_usec >>= 1;
				break;
			}
			if (n < 0) {
				if (errno == EAGAIN || errno == EINTR)
					continue;
				perror("select");
				fd = -1;
				goto done;
			}
			for (fd = 0; fd <= max; fd++) {
				if (FD_ISSET(fd, &wrset)) {
					for (j = 0; j < i; j++)
						if (fds[j] == fd)
							break;
					assert(j < i);
					/*
					 * Test to see if the connect
					 * succeeded.
					 */
					n = read(fd, NULL, 0);
					if (n == -1) {
						close(fd);
						FD_CLR(fd, &fdset);
						fds[j] = -1;
						info[j] = NULL;
						count--;
						continue;
					}
					/* Connect succeeded. */
					goto done;
				}
			}
		} while (timeout == NULL && count != 0);
	}

	/* We failed to connect. */
	fd = -1;

 done:
	/* Close all other descriptors we have created. */
	for (j = 0; j < i; j++)
		if (fds[j] != fd && fds[j] != -1) {
			close(fds[j]);
		}

	if (fd != -1) {
		/* Restore default blocking behaviour.  */
		if ((flags = fcntl(fd, F_GETFL)) != -1) {
			flags &= ~O_NONBLOCK;
			if (fcntl(fd, F_SETFL, flags) == -1)
				perror("fcntl");
		} else
			perror("fcntl");
	}

 cleanup:
	/* Free everything. */
	if (fds) free(fds);
	if (info) free(info);

	return (fd);
}
#endif

#if TESTING
int
main(int argc, char **argv) {
	int fd, n;
	struct timeval then, now;
	struct addrinfo hints, *res0;
	const char *hostname, *servname;

	hostname  = "localhost";
	if (argv[1])
		hostname = argv[1];
	servname = "http";

	/*
	 * Not all getaddrinfo() implementations support AI_ADDRCONFIG
	 * even if it is defined.  Retry without it on EAI_BADFLAGS.
	 */
	memset(&hints, 0, sizeof(hints));
	hints.ai_family = PF_UNSPEC;
	hints.ai_socktype = SOCK_STREAM;
	hints.ai_protocol = IPPROTO_TCP;
#ifdef AI_ADDRCONFIG
	hints.ai_flags = AI_ADDRCONFIG;
#endif

#ifdef AI_ADDRCONFIG
 again:
#endif
	n = getaddrinfo(hostname, servname, &hints, &res0);
	if (n != 0) {
#ifdef AI_ADDRCONFIG
		if (n == EAI_BADFLAGS && hints.ai_flags & AI_ADDRCONFIG) {
			hints.ai_flags &= ~AI_ADDRCONFIG;
			goto again;
		}
#endif
		fprintf(stderr, "getaddrinfo: %s\n", gai_strerror(n));
		exit(1);
	}

	gettimeofday(&then, NULL);
	fd = connect_to_host(res0);
	gettimeofday(&now, NULL);
	freeaddrinfo(res0);
	now.tv_sec -= then.tv_sec;
	now.tv_usec -= then.tv_usec;
	while (now.tv_sec > 0) {
		now.tv_usec += 1000000;
		now.tv_sec -= 1;
	}
	fprintf(stderr, "connect_to_host(%s) -> %d in %d ms\n", hostname, fd,
		now.tv_usec/1000);
	close(fd);
}
#endif

---

From: Mark Smith <[email-masked]>
Date: Wed, 20 Mar 2013 20:01:07 -0700 (PDT)

----- Original Message -----
> To: Mark Smith <[email-masked]>
> Sent: Thursday, 21 March 2013 1:21 PM
> in RFC6724, and that only really matters is when you are given a choice of both 
> a GUA and a ULA. The only devices for which ULA and GUA AAAA records may be 
> received will be internal devices, and that could even be made selective by 
> having the DNS resolvers only hand ULA AAAA records to internal clients if 
> necessary. Internet devices should only have GUA AAAAs.
> 

Yes. Their IPv6 router will generate an ICMPv6 destination unreachable as it doesn't have a route matching the AAAA (i.e. a default route). That will cause the browser to fall back to IPv4. When I tested this scenario in around 2010/2011 (before HE), I couldn't perceive the failure of IPv6 and fall back to IPv4.

> I'm not worried about hosts that have ULA+GUA IPv6, I'm worried about 

> the ones with only ULA IPv6 address and them trying to use this address to

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Mar 2013 14:49:17 +1100

In message <[email-masked]>, Mikael Abraha
msson writes:
>   This message is in MIME format.  The first part should be readable text,
>   while the remaining parts are likely unreadable without MIME-aware tools.
> 
> ---137064504-71882887-1363832507=:2309
> Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed
> Content-Transfer-Encoding: 8BIT
> 
 
To simulate: "telnet -6 -s fd92:7065:b8e::e5fa:8f4c:bd1a:b7ba
www.isc.org 80" which terminates in 4 and a bit seconds.  By
comparison trying to reach a dead host take 80 odd seconds before
connect fails.  Yes, my border router is configured to send back
destination unreachable if a packet with a ULA source address tries
to leave the site.

14:30:18.560162 IP6 fd92:7065:b8e::e5fa:8f4c:bd1a:b7ba.63723 > 2001:4f8:0:2::d.80: Flags [S], seq 3326326525, win 65535, options [mss 1440,nop,wscale 4,nop,nop,TS val 741847151 ecr 0,sackOK,eol], length 0
14:30:18.564477 IP6 fd92:7065:b8e::2e0:29ff:fe19:c02d > fd92:7065:b8e::e5fa:8f4c:bd1a:b7ba: ICMP6, destination unreachable,  unreachable prohibited 2001:4f8:0:2::d, length 92
14:30:19.568588 IP6 fd92:7065:b8e::e5fa:8f4c:bd1a:b7ba.63723 > 2001:4f8:0:2::d.80: Flags [S], seq 3326326525, win 65535, options [mss 1440,nop,wscale 4,nop,nop,TS val 741848154 ecr 0,sackOK,eol], length 0
14:30:19.574571 IP6 fd92:7065:b8e::2e0:29ff:fe19:c02d > fd92:7065:b8e::e5fa:8f4c:bd1a:b7ba: ICMP6, destination unreachable,  unreachable prohibited 2001:4f8:0:2::d, length 92
14:30:20.672196 IP6 fd92:7065:b8e::e5fa:8f4c:bd1a:b7ba.63723 > 2001:4f8:0:2::d.80: Flags [S], seq 3326326525, win 65535, options [mss 1440,nop,wscale 4,nop,nop,TS val 741849247 ecr 0,sackOK,eol], length 0
14:30:20.673569 IP6 fd92:7065:b8e::2e0:29ff:fe19:c02d > fd92:7065:b8e::e5fa:8f4c:bd1a:b7ba: ICMP6, destination unreachable,  unreachable prohibited 2001:4f8:0:2::d, length 92
14:30:21.781097 IP6 fd92:7065:b8e::e5fa:8f4c:bd1a:b7ba.63723 > 2001:4f8:0:2::d.80: Flags [S], seq 3326326525, win 65535, options [mss 1440,nop,wscale 4,nop,nop,TS val 741850328 ecr 0,sackOK,eol], length 0
14:30:21.782564 IP6 fd92:7065:b8e::2e0:29ff:fe19:c02d > fd92:7065:b8e::e5fa:8f4c:bd1a:b7ba: ICMP6, destination unreachable,  unreachable prohibited 2001:4f8:0:2::d, length 92
14:30:22.886610 IP6 fd92:7065:b8e::e5fa:8f4c:bd1a:b7ba.63723 > 2001:4f8:0:2::d.80: Flags [S], seq 3326326525, win 65535, options [mss 1440,nop,wscale 4,nop,nop,TS val 741851408 ecr 0,sackOK,eol], length 0
14:30:22.887977 IP6 fd92:7065:b8e::2e0:29ff:fe19:c02d > fd92:7065:b8e::e5fa:8f4c:bd1a:b7ba: ICMP6, destination unreachable,  unreachable prohibited 2001:4f8:0:2::d, length 92

Now we all have networks.  We can all test out our assumptions.

> ---137064504-71882887-1363832507=:2309
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> ---137064504-71882887-1363832507=:2309--

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 21 Mar 2013 05:30:49 +0100 (CET)

> www.isc.org 80" which terminates in 4 and a bit seconds.  By

4 seconds??? So any application without HE will need 4 seconds before 
timeouting and falling back to IPv4.

Not to mention how chatty this is, imagine almost every connection the 
user makes towards the Internet (5 years into the future when "all" 
content providers have A+AAAA) will create 3-5 ICMP unreachables before 
falling back to IPv4.

So the answer we in the IETF have is "fix your applications, they should 
use HE" and that's that?

Personally I would like to hold off using ULA until we have a better 
solution. I imagine users will have a better Internet browsing experience 
disabling IPv6 on their hosts (which is what I would imagine would happen 
at an alarming rate).

---

From: Owen DeLong <[email-masked]>
Date: Thu, 21 Mar 2013 00:17:42 -0500

I will point out that this isn't a valid test.

By using telnet -6 and/or -s fd… you force telnet to try only IPv6 with no ability to fall back to IPv4.

Without those flags, it is unlikely that it would have made multiple IPv6 attempts before falling back to IPv4, but, rather would have made one IPv6 attempt, then upon getting the unreachable, immediately try IPv4.

Owen

On Mar 20, 2013, at 11:30 PM, Mikael Abrahamsson <[email-masked]> wrote:

> 4 seconds??? So any application without HE will need 4 seconds before timeouting and falling back to IPv4.
> 
> Not to mention how chatty this is, imagine almost every connection the user makes towards the Internet (5 years into the future when "all" content providers have A+AAAA) will create 3-5 ICMP unreachables before falling back to IPv4.
> 
> So the answer we in the IETF have is "fix your applications, they should use HE" and that's that?
> 
> Personally I would like to hold off using ULA until we have a better solution. I imagine users will have a better Internet browsing experience disabling IPv6 on their hosts (which is what I would imagine would happen at an alarming rate).
> 
> --

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Mar 2013 16:57:16 +1100

> timeouting and falling back to IPv4.

Well if people didn't spoof icmp unreachables one would do.
 
> content providers have A+AAAA) will create 3-5 ICMP unreachables before 

FUD.  Modern stacks can be configured to try IPv4 except when the
target address in on the same ULA.  Been there, done that.

> So the answer we in the IETF have is "fix your applications, they should 

You need to fix the applications because they are broken.  The stack
already support what is needed.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Mar 2013 17:07:39 +1100

In message <[email-masked]>, Owen DeLong writes:
> By using telnet -6 and/or -s fd=85 you force telnet to try only IPv6 =
> with no ability to fall back to IPv4.

I was showing the IPv6 timeout.
 
> Without those flags, it is unlikely that it would have made multiple =
> IPv6 attempts before falling back to IPv4, but, rather would have made =
> one IPv6 attempt, then upon getting the unreachable, immediately try =
> IPv4.
> 
> Owen

With modern stacks you just tell them to prefer the /48 ULA you are
using and depreference all other ULA use.  If I was to disable all
other prefixes then IPv4 would be used for external connections.

% cat /etc/ip6addrctl.conf 
#Prefix                          Prec Label     
::1/128                           50     0
::/0                              40     1     
2002::/16                         30     2        
::/96                             20     3        
::ffff:0.0.0.0/96                 35     4        
fd92:7065:b8e::/48                45     5 
fc00::/7                          5      6

% 

Mark
 
> On Mar 20, 2013, at 11:30 PM, Mikael Abrahamsson <[email-masked]> =
> wrote:
> 
> >=20
> >=20
> > 4 seconds??? So any application without HE will need 4 seconds before =
> >=20
> > Not to mention how chatty this is, imagine almost every connection the =
> user makes towards the Internet (5 years into the future when "all" =
> content providers have A+AAAA) will create 3-5 ICMP unreachables before =
> falling back to IPv4.
> >=20
> > So the answer we in the IETF have is "fix your applications, they =
> should use HE" and that's that?
> >=20
> > Personally I would like to hold off using ULA until we have a better =
> solution. I imagine users will have a better Internet browsing =
> experience disabling IPv6 on their hosts (which is what I would imagine =
> would happen at an alarming rate).
> >=20
> > --=20

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 21 Mar 2013 07:54:44 +0100 (CET)

> target address in on the same ULA.  Been there, done that.

FUD? We're still talking about usage in a CPE in a residential setting, 
right?

So, I deliver this CPE to grandma and she brings home her brand new 
Windows 8 laptop and connects it. How is what you describe configured 
automatically?

> already support what is needed.

I don't agree at all. IPv6 design has fundamental problems from the get-go 
and now we need to make this work.

---

From: Mark Smith <[email-masked]>
Date: Thu, 21 Mar 2013 00:15:57 -0700 (PDT)

----- Original Message -----
> To: Mark Andrews <[email-masked]>
> Sent: Thursday, 21 March 2013 5:54 PM
> So, I deliver this CPE to grandma and she brings home her brand new Windows 8 
> laptop and connects it. How is what you describe configured automatically?
> 

ICMPv6 Destination Unreachables do not have be enabled, they are standard IPv6 router functionality.

> and now we need to make this work.

IPv6 has been enabled by default on all new Internode customer's broadband connections for the last 18 months, and all CPE they've sold have had it enabled by default. If IPv6 didn't work, the following forum would be full of complaints:

http://forums.whirlpool.net.au/forum/68

 I understand the same thing has occurred with the Free.fr network in France.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 21 Mar 2013 08:20:40 +0100 (CET)

> ICMPv6 Destination Unreachables do not have be enabled, they are standard IPv6 router functionality.

That is not what I asked about.

> IPv6 has been enabled by default on all new Internode customer's 
> broadband connections for the last 18 months, and all CPE they've sold 
> have had it enabled by default. If IPv6 didn't work, the following forum 
> would be full of complaints:

I am not talking about generic IPv6 GUA. I am talking about the case where 
there is IPv6 ULA but not GUA, and IPv4 GUA or RFC1918 address.

I have had IPv6 GUA with DHCPv6-PD at home since 2008-2009, I know it 
works just fine, thank you.

---

From: Ray Hunter <[email-masked]>
Date: Thu, 21 Mar 2013 08:36:34 +0100

> Fred Baker (fred) <mailto:[email-masked]>
> 20 March 2013 21:41
>
> </chair>
> <snip>
>
> I think the primary issue that people are really raising here is
> "please don't NAT". IMHO, there are already NAT66 products out there,
> and I have customers chomping at the bit to deploy them. I agree that
> stateful NAT was at best an evil we chose to live with. I'm not sure
> that complaining about them will make them go away. But in a world
> without NATs, there are still valid uses for a prefix that is
> advertised only within a bounded domain. I do wonder why we are so
> bent on tossing the baby while we complain about the bathwater.
>
In my mind, the fundamental problem is the implied default route
associated with NPTv6, NAPT and other NAT-like technologies.

If you don't install an implied default route on end hosts, anyone using
NAT-like technologies will suffer complete disconnection.

If you do install an implied default route, everyone (including people
who don't want to support NAT at all) are forced to bloat their code to
deal with it for situations where a default route would be inappropriate
(e.g. walled gardens advertising an RFC1918 or ULA only, but not
offering global connectivity), or they'll suffer long connection times
or timeouts.

regards,
RayH

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 21 Mar 2013 08:53:55 +0100

Le 20/03/2013 21:03, Owen DeLong a écrit :
>>> What worries me is that in non-zeroconf environments, or those
>>> where manual override is possible, administrators will use
>>> fc00::/48, as it's easier to type/remember.
>>

In a sense yes, but what better could one do? DEsign a better way to
generate this uniqueness? There are ways for that, like starting from
truly unique application-specific immutable IDs which hardly ever
experienced collisions (like MAC-based did).

>>> I see only one difference between ULA and 10/8. That difference
>>> is *not* that ULAs are unique, because as you correctly note
>>> above, there is no hope of them actually being unique in the real
>>> world.
>>

There could be ways to be less idealistic and yet come up with unique
ULAs in certain contexts.

>> Anyone who tried to configure ULAs according to that RFC knows
>> that there is some  level of uniqueness guaranteed.
>
>
> No, there is no level of uniqueness guaranteed. There is a
> statistically high probability of uniqueness for those who deploy
> ULA according to the RFC. Even there, there is no guarantee of any
> level of uniqueness, just a strong probability.

I think this statement assumes exclusively the suggested ULA generation
algorithm in the RFC. But better algorithms could be made which remove
that probability factor, in certain contexts.

> However, the probability that the majority of administrators will
> even read the ULA RFC (how many people do you think have actually
> read RFC-1918 vs. the number that have deployed 10/8 or any other
> RFC-1918 address? I'll give you a hint... Ask a bunch of
> administrators which of the following are RFC-1918 addresses. If
> it's not an open book test, I bet the results surprise you.

I agree in a sense, I let myself surprised by that. But things could be
done about it.

> 		172.80.15.7		About half of the ones that got the previous question wrong will

I got them all wrong at a quick view.  I'd have to read the RFC1918 and 
find the prefix length of the 172. private addresses to do it right. 
Fortunately there's that RFC.

> fd::1/64 isn't even ULA, but I wouldn't put it past administrators to think it is.

Corrected.  It's not fd::1/64 but fd00::1/64.

> fd00::1/64, OTOH, will probably be the most common ULA gateway address.

Let's put that in a document! State upfront that sysadmins should not
assign fd00::1/64 on any interface (be that default or not) because it
doesnt have enough intermediary bits such that to be unique - not an ULA
by RFC.

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 21 Mar 2013 01:41:56 -0700

On Wed, Mar 20, 2013 at 8:01 PM, Mark Smith <[email-masked]>wrote:

> Yes. Their IPv6 router will generate an ICMPv6 destination unreachable as
> it doesn't have a route matching the AAAA (i.e. a default route). That will
> cause the browser to fall back to IPv4.
>

Incorrect. RFC 1122, section 4.2.3.9: "Since these Unreachable messages
indicate soft error conditions, TCP MUST NOT abort the connection".

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 21 Mar 2013 01:44:42 -0700

> Example C code is attached.  Just pick if you want select/poll/thread

Your example is 600 lines of code. looping through getaddrinfo() results is
an order of magniture shorter.

> #define TIMEOUT 100     /* 100 ms */

Users don't want to wait 100ms on every connection.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Mar 2013 19:53:17 +1100

In message <CAKD1Yr2JdyJM=spRcUOPhFWqHk=[email-masked]>
> indicate soft error conditions, TCP MUST NOT abort the connection".

No connection yet exists.  A embrionic connection exists and has
been shown port unreachables do reduce the connection timeout.  Note
this is moot when a the address selection table takes into account
ULA properties.

Configurable address selection tables have been part of the IPv6
spec since 2003 and have existed in implementations since then.

Mark

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 21 Mar 2013 01:58:20 -0700

On Thu, Mar 21, 2013 at 1:53 AM, Mark Andrews <[email-masked]> wrote:

> No connection yet exists.

I disagree, but that doesn't matter. What does matter is that major
implementations disagree.

- Windows entirely ignores the unreachables
- OS X (and iOS?) times out after four seconds

The only major implementation that does what you say is Linux.

> A embrionic connection exists and has been shown port unreachables do
> reduce the connection timeout.

Not really; see above.

> Note this is moot when a the address selection table takes into
> account ULA properties.
>

No implementation does this in its default configuration.

> spec since 2003 and have existed in implementations since then.

If you configure them yourself (except on OS X/iOS where they're not
supported at all), sure.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 21 Mar 2013 10:18:45 +0100 (CET)

On Thu, 21 Mar 2013, Mark Andrews wrote:

> Configurable address selection tables have been part of the IPv6 spec 
> since 2003 and have existed in implementations since then.

What's the opposite of FUD? Wishful thinking? As stated before, this 
doesn't work for grandma. She needs the address selection table be 
remotely automatically provisioned. As far as I know, this is not the case 
in current implementations.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 21 Mar 2013 10:29:41 +0100 (CET)

On Thu, 21 Mar 2013, Mikael Abrahamsson wrote:

>From rfc6204bis:

ULA-5:  An IPv6 CE router MUST NOT advertise itself as a default
            router with a Router Lifetime greater than zero whenever all
            of its configured and delegated prefixes are ULA prefixes.

Doesn't this make routed home useless as soon as the IPv6 Internet 
connectivity goes away? The ULAs won't get routed anymore (solving my 
problem), but it also makes the desired functionality (printer still works 
when ISP connection is down) go away as well. Right?

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Mar 2013 20:31:37 +1100

> an order of magniture shorter.

My example had 3 different methods of connecting in it.  Splitting
the code out into the seperate methods.

     226    poll-connect.c
     248    select-connect.c
     324    thread-connect.c

http://users.isc.org/~marka/index.html

As for the naive loop across getaddrinfo() results, that is how we
are in this place to start with.  One needs something smarter.  You
put the code in a library an call it.

> Users don't want to wait 100ms on every connection.

And users want us to repeal the laws of physics.

100 ms is reasonable amount of time to wait given the size of the
planet and the speed of light.  Remember this delay does not happen
if the address selection table is properly configured.

Mark

---

From: Ole Troan <[email-masked]>
Date: Thu, 21 Mar 2013 10:37:03 +0100

Mikael,

> Doesn't this make routed home useless as soon as the IPv6 Internet connectivity goes away? The ULAs won't get routed anymore (solving my problem), but it also makes the desired functionality (printer still works when ISP connection is down) go away as well. Right?

no, routing internally will still work.

cheers,
Ole

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Mar 2013 20:42:05 +1100

> - OS X (and iOS?) times out after four seconds

OS X takes 80 seconds to timeout the connection it there are no
port unreachables.  I measured it.
 
> The only major implementation that does what you say is Linux.

Yet the test was done on a OS X box.

% time telnet -s 2001:470:1f00:820:7dc1:7bde:ed0f:15aa 2001:ffff::1 80
Trying 2001:ffff::1...
telnet: connect to address 2001:ffff::1: Operation timed out
telnet: Unable to connect to remote host
0.027u 0.013s 1:15.77 0.0%	0+0k 0+0io 0pf+0w
% time telnet -s fd92:7065:b8e::e5fa:8f4c:bd1a:b7ba 2001:4f8:0:2::d 80
Trying 2001:4f8:0:2::d...
telnet: connect to address 2001:4f8:0:2::d: Connection refused
telnet: Unable to connect to remote host
0.026u 0.012s 0:04.47 0.6%	0+0k 0+0io 0pf+0w
% uname -a
Darwin drugs.dv.isc.org 12.3.0 Darwin Kernel Version 12.3.0: Sun Jan  6 22:37:10 PST 2013; root:xnu-2050.22.13~1/RELEASE_X86_64 x86_64
% 
 
> No implementation does this in its default configuration.

Defaults can change.
 
> If you configure them yourself (except on OS X/iOS where they're not

Well we should complain to Apple.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 21 Mar 2013 10:42:22 +0100

Le 21/03/2013 10:29, Mikael Abrahamsson a écrit :
> problem), but it also makes the desired functionality (printer still
> works when ISP connection is down) go away as well. Right?

In a sense I agree. This ULA-5 requirement forbids growth of large
home-to-home networks.

This ULA-5 requirement is wrong and shouldnt be there - neither for CPEs
nor for anything else.

A Router - any Router for that matter - should be able to be a default
router, or not a default router, whenever it wants to, even though it
has no connection to Internet.

If this is not done (i.e. do not allow default routers when only ULA
addresses are used) then the networks using exclusively ULA addressing
can not scale to large size, because there may be too many routes at too
many Routers. An advantage of using a default route is that it
concentrates the many routes only in a few-places - the DFZ.

Alex

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 21 Mar 2013 10:49:58 +0100 (CET)

> no, routing internally will still work.

If Router Lifetime is zero (which it should be as soon as Internet 
connectivity goes down and now it's only ULA left), won't that invalidate 
the default route the clients have installed?

---

From: Ole Troan <[email-masked]>
Date: Thu, 21 Mar 2013 10:53:12 +0100

Mikael,

> If Router Lifetime is zero (which it should be as soon as Internet connectivity goes down and now it's only ULA left), won't that invalidate the default route the clients have installed?

correct. that's why there is L-3. there will be more specific routes advertised for the internal ULA prefix(es).

cheers,
Ole

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 21 Mar 2013 10:55:36 +0100

Le 21/03/2013 10:53, Ole Troan a écrit :
> Mikael,
>
>>>> ULA-5:  An IPv6 CE router MUST NOT advertise itself as a
>>>> default router with a Router Lifetime greater than zero
>>>> whenever all of its configured and delegated prefixes are ULA
>>>> prefixes.
>>>>
>>>> Doesn't this make routed home useless as soon as the IPv6
>>>> Internet connectivity goes away? The ULAs won't get routed
>>>> anymore (solving my problem), but it also makes the desired
>>>> functionality (printer still works when ISP connection is down)
>>>> go away as well. Right?
>>>
>> connectivity goes down and now it's only ULA left), won't that
>> invalidate the default route the clients have installed?
>
> correct. that's why there is L-3. there will be more specific routes
> advertised for the internal ULA prefix(es).

Whenever there are specific routes it means it won't scale to large 
sizes.  This is not good - it doesnt scale.

Alex

>
> cheers, Ole _______________________________________________ v6ops
> mailing list [email-masked]

---

From: Ole Troan <[email-masked]>
Date: Thu, 21 Mar 2013 10:56:39 +0100

> concentrates the many routes only in a few-places - the DFZ.

that's incorrect. see my reply to Mikael.
check the earlier RFC6204 threads if you want history.

cheers,
Ole

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Mar 2013 20:57:52 +1100

> Well we should complain to Apple.

And OS X has good defaults.  So can we please stop saying this does
not work when it does with current commercial OSs.  If your favorite
OS does the wrong thing complain to your OS vendor.

% time telnet www.isc.org 80 < /dev/null
Trying 149.20.64.42...
Connected to www.isc.org.
Escape character is '^]'.
Connection closed by foreign host.
0.027u 0.013s 0:00.82 3.6%	0+0k 0+0io 0pf+0w
% ifconfig en1
en1: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
	ether 60:33:4b:01:75:85 
	inet6 fe80::6233:4bff:fe01:7585%en1 prefixlen 64 scopeid 0x5 
	inet 192.168.191.223 netmask 0xffffff00 broadcast 192.168.191.255
	inet6 fd92:7065:b8e::6233:4bff:fe01:7585 prefixlen 64 autoconf 
	inet6 fd92:7065:b8e::f9bc:650f:95f3:5de6 prefixlen 64 autoconf temporary 
	media: autoselect
	status: active
% 

Mark

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 21 Mar 2013 10:58:45 +0100 (CET)

> advertised for the internal ULA prefix(es).

How widely is RFC4191 section 2.3 (Route information option) supported in 
currently deployed end systems?

---

From: Wuyts Carl <[email-masked]>
Date: Thu, 21 Mar 2013 10:56:26 +0100

But Alexandru, isn't this going 1 step too far ?
You want to step back the "no def route allowed for ULA" principle ?
It's about CPE devices, so I don't see why there would be all of a sudden too many routes in some of these use cases ??
Please elaborate.

Regs
Carl

> works when ISP connection is down) go away as well. Right?

In a sense I agree. This ULA-5 requirement forbids growth of large home-to-home networks.

This ULA-5 requirement is wrong and shouldnt be there - neither for CPEs nor for anything else.

A Router - any Router for that matter - should be able to be a default router, or not a default router, whenever it wants to, even though it has no connection to Internet.

If this is not done (i.e. do not allow default routers when only ULA addresses are used) then the networks using exclusively ULA addressing can not scale to large size, because there may be too many routes at too many Routers. An advantage of using a default route is that it concentrates the many routes only in a few-places - the DFZ.

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 21 Mar 2013 03:04:39 -0700

Ok, so you're saying that we should specify behaviour that won't work well
on any current hosts, that we should use mechanisms to get around this that
don't work at all on a substantial number of hosts (OS X/iOS), that that we
need to complicate all apps to deal with this, and that 4 seconds is
acceptable.

And you're saying this because then we can use ULAs. But... why?

On Thu, Mar 21, 2013 at 2:42 AM, Mark Andrews <[email-masked]> wrote:

>
> In message <CAKD1Yr0pbq7L0T55ZLpk1UnoMB981NZE=94nBUeh+Rv=
> [email-masked]>, Lorenzo Colitti writes:
> >
> Darwin drugs.dv.isc.org 12.3.0 Darwin Kernel Version 12.3.0: Sun Jan  6
> 22:37:10 PST 2013; root:xnu-2050.22.13~1/RELEASE_X86_64 x86_64
> %
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 21 Mar 2013 03:05:51 -0700

On Thu, Mar 21, 2013 at 2:57 AM, Mark Andrews <[email-masked]> wrote:

> not work when it does with current commercial OSs.

When did the defaults change? How many users have the old and the new
behaviour?

---

From: Philipp Kern <[email-masked]>
Date: Thu, 21 Mar 2013 11:12:47 +0100

Owen,

am Wed, Mar 20, 2013 at 03:58:51PM -0500 hast du folgendes geschrieben:
> Remember, the RIRs are not for profit entities. Larger quantities of end-user
> registrations should directly equate to lower fees.

only if it can be automated. If you still need to have people reviewing
contracts, checking a company's registration and stuff you'd likely need more
people to process them, which means higher cost.

If it were similar to the domain registries, I'd tend to agree that the price
should be much lower. Like the LIR checking all requirements, have the RIR
trust the LIR on this and automatically give out PI assignments up to a
certain size.

Kind regards
Philipp Kern

---

From: Ole Troan <[email-masked]>
Date: Thu, 21 Mar 2013 11:48:20 +0100

Alex,

> Whenever there are specific routes it means it won't scale to large sizes.  This is not good - it doesnt scale.

it is not meant to. RFC6204 describes a single router in the home. are you expecting more than 17 ULA prefixes (/48s) in the home?
the homenet architecture has no such limitation.

the reason for the RFC6204 text is that a host with a default route and a ULA address would not behave well.

cheers,
Ole

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Mar 2013 21:48:29 +1100

I'm saying apps need to be fixed regardless.  We are in a multi-homed
world once you turn on IPv6.  Waiting 60 odd seconds for failover
is not acceptable and never has been.  The only reason it hasn't
been fixed in the past is that most servers present as single homed.
Once you are dual stacked there are no single homed servers.

Links break on the internet.  Those breaks may take out IPv4
connectivity, IPv6 connectivity or both IPv4 and IPv6 connectivity
between pairs of sites.  Apps should cope and they don't need
additional assistance from the OS to cope.

I'm also saying that modern OS do a reasonable job.  If your OS
doesn't complain to the vendor.  All the vendors push out updates
these days.  All vendors are trying to provide a good experience.

If your OS makes a wrong initial choice and the apps hasn't been
updated, the fallback is still only ~4 secs rather than 60 odd if
you are using ULA with only a IPv4 uplink.

Mark

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Mar 2013 12:30:08 +0000

On 21/03/2013 09:18, Mikael Abrahamsson wrote:
> remotely automatically provisioned. As far as I know, this is not the
> case in current implementations.

This is the IETF, where we write specs for future implementations.

   Brian

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 21 Mar 2013 14:18:47 +0100

> But Alexandru, isn't this going 1 step too far ?

Ok - it is going a little further but not too far.

> You want to step back the "no def route allowed for ULA" principle ?

I didnt know there were such a principle, but it should be considered.

> It's about CPE devices, so I don't see why there would be all of a
> sudden too many routes in some of these use cases ?? Please
> elaborate.

In an appartment building there may be several CPEs inter-connected.
Within one appartment there may be a single ULA prefix.

If one Client PC needs to talk to another Client PC in another
appartment then each CPE should have a route for each other CPE.  And
each one of these routes should be told to each Client PCs.

The more the appartments the more routes.

Small Client PC == little memory, long search time.

OTOH, if one were to use default routes, then the Client PC would need
to store a single default route.

Alex

> Regs Carl
>> router with a Router Lifetime greater than zero whenever all of its
>> configured and delegated prefixes are ULA prefixes.
>>
>> connectivity goes away? The ULAs won't get routed anymore (solving
>> my problem), but it also makes the desired functionality (printer
>> still works when ISP connection is down) go away as well. Right?
>
> A Router - any Router for that matter - should be able to be a
> default router, or not a default router, whenever it wants to, even
> though it has no connection to Internet.
>
>  addresses are used) then the networks using exclusively ULA
> addressing can not scale to large size, because there may be too many
> routes at too many Routers. An advantage of using a default route is
> that it concentrates the many routes only in a few-places - the DFZ.
>
> Alex
>
>>
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 21 Mar 2013 14:20:39 +0100

Le 21/03/2013 10:54, Ole Troan a écrit :
>>> router with a Router Lifetime greater than zero whenever all of
>>> its configured and delegated prefixes are ULA prefixes.
>>>
>> If this is not done (i.e. do not allow default routers when only
>> ULA addresses are used) then the networks using exclusively ULA
>> addressing can not scale to large size, because there may be too
>> many routes at too many Routers. An advantage of using a default
>> route is that it concentrates the many routes only in a few-places
>> - the DFZ.
>

YEs, there is something incorrect above, but not all.

In whatever network one builds - use default routes, it's a good thing.
  Don't forbid default routes.

Alex

> cheers, Ole

---

From: Ole Troan <[email-masked]>
Date: Thu, 21 Mar 2013 14:23:34 +0100

Alex,

> Don't forbid default routes.

agree, we'll fix that as soon as the host implementations are fixed.

cheers,
Ole

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 21 Mar 2013 14:23:12 +0100

Le 21/03/2013 10:58, Mikael Abrahamsson a écrit :
>> correct. that's why there is L-3. there will be more specific
>> routes advertised for the internal ULA prefix(es).
>
> How widely is RFC4191 section 2.3 (Route information option)
> supported in currently deployed end systems?

Good question - and even if it where -  it were _only_ to configure Hosts.

I.e. it doesnt allow to configure a router at home (other than the CPE).

A router at home may have two interfaces each with ULA, no GUA
addressing; and have the CPE as its Default Router, and be itself a
Default Router for its Clients.

Alex

---

From: Wuyts Carl <[email-masked]>
Date: Thu, 21 Mar 2013 14:22:22 +0100

Well, seems like there is some misunderstanding here.  If all inhabitants from all these appts know each other and want to be directly connected through ULA's, you can hardly talk about home CPEs I'd say, no ?

Regs
Carl

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: donderdag 21 maart 2013 14:19
To: Wuyts Carl
Cc: [email-masked]
Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis)

> sudden too many routes in some of these use cases ?? Please elaborate.

If one Client PC needs to talk to another Client PC in another appartment then each CPE should have a route for each other CPE.  And each one of these routes should be told to each Client PCs.

OTOH, if one were to use default routes, then the Client PC would need to store a single default route.

Alex

> can not scale to large size, because there may be too many routes at 
> too many Routers. An advantage of using a default route is that it

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 21 Mar 2013 14:25:57 +0100 (CET)

> This is the IETF, where we write specs for future implementations.

The IETF also tries to make the Internet work. That means take into 
account what the real world looks like before we give guidance.

Especially an "analysis" document should take into account what the real 
world looks like and what problems will occur due to existing 
implementations that correctly implemented standards existing at the time.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 21 Mar 2013 14:27:02 +0100

Le 21/03/2013 11:47, Ole Troan a écrit :
> Alex,
>
>>>> If Router Lifetime is zero (which it should be as soon as
>>>> Internet connectivity goes down and now it's only ULA left),
>>>> won't that invalidate the default route the clients have
>>>> installed?
>>>
>> Whenever there are specific routes it means it won't scale to
>> large sizes.  This is not good - it doesnt scale.
>
> it is not meant to. RFC6204 describes a single router in the home.

Ok - yes.

But does it consider _several_ such Homes talking directly one to 
another without going through the ISP?  If not then it should.

> are you expecting more than 17 ULA prefixes (/48s) in the home?

Not that many.  Less.

> the homenet architecture has no such limitation.

Ok.

> and a ULA address would not behave well.

Well, I dont see why?  I have some in the lab doing so - it has a ULA 
address and a default route and it works fine - it pings another ULA 
behind that default route.

Is this a MacOS-only software problem?

Or is it actually a source address selection problem?  Or a src-based 
route problem...

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 21 Mar 2013 14:29:55 +0100

Le 21/03/2013 14:22, Wuyts Carl a écrit :
> Well, seems like there is some misunderstanding here.  If all
> inhabitants from all these appts know each other and want to be
> directly connected through ULA's, you can hardly talk about home
> CPEs I'd say, no ?

I dont know why?  Home CPEs are forbidden from talking to each other?

Alex

>
> Regs Carl
>
>
>
>
>
> -----Original Message----- From: Alexandru Petrescu
> [mailto:[email-masked]] Sent: donderdag 21 maart 2013
> 14:19 To: Wuyts Carl Cc: [email-masked] Subject: Re: [v6ops]
> questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis)
>
> appartment then each CPE should have a route for each other CPE.
> And each one of these routes should be told to each Client PCs.
>
>> default router, or not a default router, whenever it wants to,
>> even though it has no connection to Internet.
>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 21 Mar 2013 14:32:37 +0100

Le 21/03/2013 14:23, Ole Troan a écrit :
>>>>> functionality (printer still works when ISP connection is
>>>>> down) go away as well. Right?
>>>>
>>>> If this is not done (i.e. do not allow default routers when
>>>> only ULA addresses are used) then the networks using
>>>> exclusively ULA addressing can not scale to large size, because
>>>> there may be too many routes at too many Routers. An advantage
>>>> of using a default route is that it concentrates the many
>>>> routes only in a few-places - the DFZ.
>>>
>> In whatever network one builds - use default routes, it's a good
>> thing. Don't forbid default routes.
>

Ole - sorry, do you mean my vanilla linux radvd won't set Lifetime in RA
to 0 if I put only ULAs on its interfaces?  (I might as well try it...)

Alex

---

From: Wuyts Carl <[email-masked]>
Date: Thu, 21 Mar 2013 14:36:31 +0100

So, where do you draw the line, serve a full campus too ?
I'd say there's a difference on how/where you use CPEs, but hey, this is just my personal opinion.  If you want to directly talk to your customers through def routes, I'd say you might bump into issues that the ULA used might not be so "unique", after all, it's private.  How will you know the ULA used by your neighbor ?  what if it is not persistently saved ? ...

Anyway, don't want to keep discussing, seems your mind is made up, fair enough, no problem.
Technicolor is the worldwide # 1 (del oro) in residential CPEs, and the situation you describe is not really fitting in, but it can be done of course, still, limitations will exist, so you will bump onto some boundaries anyway.

regs

Carl

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: donderdag 21 maart 2013 14:30
To: Wuyts Carl
Cc: [email-masked]
Subject: Re: [v6ops] questions regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis)

Le 21/03/2013 14:22, Wuyts Carl a écrit :
> directly connected through ULA's, you can hardly talk about home CPEs 
> I'd say, no ?

Alex

> 14:19 To: Wuyts Carl Cc: [email-masked] Subject: Re: [v6ops] questions 
> regarding rfc6204bis ( draft-liu-v6ops-ula-usage-analysis)
>

---

From: Ole Troan <[email-masked]>
Date: Thu, 21 Mar 2013 14:44:38 +0100

Alex,

Tore Anderson did the testing I quoted below in December 2010:
if you or someone else could redo that with the latest software and can ensure us that 
there no longer are problems with IPv6 breakage, that would be great.

cheers,
Ole

----------------

Keep in mind that ULAs are p.t. considered no different from any other
globally scoped IPv6 address.  No current host implementation is
special-casing the ULA WKP in any way.  This cannot be considered a bug,
in my opinion, as the document that will change this is yet to be
published by the IETF (draft-ietf-6man-rfc3484-revise).  With that in
mind, here's a summary of current host behaviour for a host configured
with ULA or any other bogon/non-routed global IPv6 address, that
attempts to contact a global dual-stacked destination:

Case 1) default IPv6 route, no ICMPv6 errors from network:

Windows:   21 second timeout in connect() for every published AAAA
Mac OS X:  75 second timeout in connect() for every published AAAA
Linux:     190 second timeout in connect() for every published AAAA

Case 2) default IPv6 route, ICMPv6 errors from network:

Windows:   like case #1 (ICMPv6 errors appears to be ignored)
Mac OS X:  four second timeout in connect() (it retransmits TCP SYNs
          five five times with 1-second intervals before giving up)
Linux:     instant (i.e. ~RTT to ICMPv6 source) failback to IPv4

Case 3) no default IPv6 route:

Windows:   internal «no route to host» generated by IP stack, instant
          fallback to IPv4
Mac OS X:  like Windows
Linux:     like Windows

Tested versions were Windows 7, Mac OS X 10.6.5, and Fedora 14 (Linux
2.6.35.9).

So, the cases where the user remains a «happy eyeball» is #3, and for
Linux users only, #2.

Also it's worth noting that these timeouts occur for every single
connection attempt.  While it doesn't sound too bad to endure a
four-second timeout (case #2, Mac OS X) to load a web page, all but the
most simplest web pages usually have a multitude of elements included,
often nested.  So a four second timeout will quickly add up to a minute
or more for HTTP traffic, which is clearly unacceptable performance both
for the end user and for the content provider.

Current Mac OS X, however, has a bug in that it will install a default
IPv6 route if it receives an RA with a lifetime of 0, provided that it
has no current information that was derived from an earlier RA with a
lifetime of >0.  In other words, invalidating a previously announced
default route works, but continuously announcing a ULA prefix in an RIO
with lifetime=0 will not work as expected.

This, however, is clearly a bug and I'm optimistic that it can be fixed
by Apple in a timely fashion (at least, it seems more likely than
implementing 3484bis or Happy Eyeballs).  Also, even if it is not fixed
it will "only" mean a four-second connect timeout for the affected
users, so in my opinion this is an acceptable compromise that allows the
cpe-router draft to realise the ambition of a routed home network usin
ULAs while at the same time avoiding ruining the party for the content
providers that wants to deploy IPv6.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 21 Mar 2013 14:55:58 +0100

Le 20/03/2013 21:49, Owen DeLong a écrit :
>> Le 20/03/2013 14:18, Owen DeLong a écrit : [...]
>> GUA (Global Unicast Addresses) is a good temptation to be used in
>> all cases, even in disconnected operation.
>>
>> But, one should consider the cases of re-connection of moving
>> networks at different places in the Internet, successively.
>>
>

(I must say first that I discover the meaning of PI GUA - Provider-
  Independent Global Unicast Address; it is possible for an Enterprise
  to request a PI GUA (a prefix actually, I believe) and multi-home that
  Enterprise to one or several Providers.)

(I must also say that all below may not be that true).

A PI GUA for 2-3 Enterprises may work connected mostly all the time at
the same 2-3 places.  But I think 1 billion PI GUAs moving around the
Internet at the speed of 1 new connection/minute may not work - it
involves 'route churning', i.e. too many routing protocol messages per
second and too large routing table entries.  Isnt't there a risk like that?

I have no figures though.

>> In these cases there may be a risk, because a GUA is valid only at
>> one topological place.  Moving elsewhere one should use a
>> different GUA.
>>
>

?  Is this something specified in the address?  (I heard of prefix
coloring?)

>> Should we allow two vehicles which have GUAs and meet each other
>> to talk to each other directly?  At that point would topological
>> correctness still be respected with respect to ingress filtering?
>> (what if one of the vehicles _is_ connected to the Internet).
>
> Seems to me that this is an ideal application for either BGP or MIP,

Right... we've seen experiments of BGP with planes, and of other
vehicles with MIP.

> depending on the various factors involved in the nature of the
> communication between those vehicles and/or their other topological
> relationships. Perhaps even a combination of BGP and MIP.

That would be new.

>> (I am not saying that ULA completely solves this, but that the use
>> of GUA in disconnected operation may be a less tempting
>> invitation).
>

Well, we can't just put GUAs in all vehicles of a manufacturer because
these GUAs aren't topologically correct everywhere in the Internet.
Puting there PI GUAs instead of GUA doesn't help, because they too can't
be guaranteed to avoid 'route churn' when we talk large number of
vehicles and many different points of connecting to the Internet (large
area of mobility like continents).

To solve 'route churn' one may use Mobile IP (or other protocol for
supporting mobility) - all need an Anchor point in the infrastructure,
to which to tunnel.  If there's not such Anchor then there's no GUA
possible.

But the topology corectness and ingress filtering come into question
only if we need these vehicles to talk to someone in the Internet - were
them to just talk to each other then there wouldn't be a risk of Route
Churn - these vehicular networks are not as large as the Internet (will
they ever be).

Hence we use ULAs.

And, when one can have Anchors, one also uses GUAs at the same time as
ULAs.  One may also use only ULA between a vehicle and its Manufacturer
- yet not to the Internet at large.

This is a question of where to define the boundary of ULA.  Where sits
the Border Router?  And what's the site?  And how to form addresses
which are sure to be unique enough witin that site.

It's not a question of ULA vs GUA.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 21 Mar 2013 15:01:08 +0100

Le 20/03/2013 21:41, Fred Baker (fred) a écrit :
[...]
> "please don't NAT". IMHO, there are already NAT66 products out

I agree!  NAT66 is a very tempting technology for vehicular networks as
well.

It is so surprising how there are so many IPv6 specifications for
vehicular communications relying on the fact that in IPv6 there is no
NAT... and now this ip6tables MASQUERADE (i.e. NAT66) alone which is not
even specified may turn everything upside down.

Alex

> and I have customers chomping at the bit to deploy them. I agree
> that stateful NAT was at best an evil we chose to live with. I'm not
> sure that complaining about them will make them go away. But in a
> world without NATs, there are still valid uses for a prefix that is

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Mar 2013 14:10:10 +0000

On 21/03/2013 13:55, Alexandru Petrescu wrote:
...
> second and too large routing table entries.  Isnt't there a risk like that?

Well, it was three or four orders of magnitude smaller, but there were a lot
of complaints about the churn produced by Connexion by Boeing, which was
effectively a few hundred IPv4 PI prefixes moving around at almost Mach 1.

OK, it's not a fair comparison, but I think we're on safe ground in doubting
that increasing from 30k to millions of PI prefixes will work smoothly.

    Brian

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 21 Mar 2013 15:10:32 +0100

> So, where do you draw the line, serve a full campus too ?

YEs - a full campus as well.  And even its sister campus if there it
were. (multi-site Enterprises...)

> I'd say there's a difference on how/where you use CPEs, but hey, this
> is just my personal opinion.  If you want to directly talk to your
> customers through def routes, I'd say you might bump into issues that
> the ULA used might not be so "unique", after all, it's private.

That uniqueness is embedded in the way the ULAs are generated.  The RFC
gives an example algorithm.

That algorithm should be improved (maybe also because it says 'SHA-1').
  And there should be many variants of that algorithm.

FOr each such site the uniqueness aspect can be derived from the nature
of the site.  If the site were a Zoo then use the animal names to form
the unique ULAs and state that the Border Router is at the top of the Zoo.

> How will you know the ULA used by your neighbor ?  what if it is not
>  persistently saved ? ...

That is right, I dont know how... maybe DNS, DNS Update? (once we say
which protocol is used between neighbors to update their routes, then we
can say also whether DHCP is involved, and thus DNS and so).

> Anyway, don't want to keep discussing, seems your mind is made up,
> fair enough, no problem. Technicolor is the worldwide # 1 (del oro)
> in residential CPEs, and the situation you describe is not really
> fitting in, but it can be done of course, still, limitations will
> exist, so you will bump onto some boundaries anyway.

YEs - barriers are defined here, at the same time as the ULA formation
algorithms.

Alex

> 14:30 To: Wuyts Carl Cc: [email-masked] Subject: Re: [v6ops]
>> [mailto:[email-masked]] Sent: donderdag 21 maart
>> 2013 14:19 To: Wuyts Carl Cc: [email-masked] Subject: Re: [v6ops]
>>> It's about CPE devices, so I don't see why there would be all of
>>>  a sudden too many routes in some of these use cases ?? Please
>>> elaborate.
>>
>> In an appartment building there may be several CPEs
>> inter-connected. Within one appartment there may be a single ULA
>> prefix.
>>
>>>  route is that it concentrates the many routes only in a
>>> few-places - the DFZ.
>>>
>>> Alex
>>>
>>>>
>>>
>>>
>>> _______________________________________________ v6ops mailing

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Mar 2013 14:17:09 +0000

> I dont know why?  Home CPEs are forbidden from talking to each other?

There's a terminology problem here. The phrase "customer premises
equipment" implies that there's a customer and an incumbent telco,
and that is the only relationship to be considered. That's the context
for RFC6204(bis). Alexandru is talking about a homenet router, that
may have multiple service provider relationships plus neighbourhood
relationships. That's a different "business model" entirely, and there
is no reason in principle why a group of neighbours can't route among
themselves using prefixes that are nothing to do with any ISP.

    Brian

---

From: Owen DeLong <[email-masked]>
Date: Thu, 21 Mar 2013 09:18:50 -0500

> % cat /etc/ip6addrctl.conf 

Remind me where I configure the router to send the contents of ip6addrctl.conf down to the SLAAC client... Oh, right...

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 21 Mar 2013 09:33:08 -0500

> experienced collisions (like MAC-based did).

As I said at the time ULA was discussed, the best thing would have been to recognize GUA as a preferable alternative and make better provisions for GUA to be used for disconnected networks. Unfortunately, at this point, that ship has sailed. Now it boils down to limiting the damage done by ULA. To do that, we need to recognize that ULA can and will be deployed stupidly in spite of the warnings in the ULA RFCs. As a result, we should avoid creating additional RFCs which depend on ULA not being deployed stupidly and make sure, instead, that future RFCs are designed with this expectation in mind.

> ULAs in certain contexts.

Sure, but we can't rationally depend on that happening in all cases which is what you were proposing in claiming that there is "much hope".

> that probability factor, in certain contexts.

OK, so now I'm confused. First you argue that the ULA RFC as is provides
uniqueness and we can ignore the fact that it won't be reliably implemented
per the RFC. Now you're arguing that violating the RFC is an even better
way to go so that we can get guaranteed uniqueness?

It is precisely the tendency for ULA discussions to spiral into tight little circles
like this that convinces me that ULA is a quagmire which causes many more
problems than it solves.

> I agree in a sense, I let myself surprised by that. But things could be

Such as?

> I got them all wrong at a quick view.  I'd have to read the RFC1918 and find the prefix length of the 172. private addresses to do it right. Fortunately there's that RFC.

10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16

Yes, but how many of the IT professionals running IPv4 RFC-1918 addressed networks even know the number? How many of those have actually read the RFC? (If it's more than 5% I would be very surprised). Do you have any idea how many people I talk to that still say "RFC-1597?"

> Corrected.  It's not fd::1/64 but fd00::1/64.

That's at least ULA...

> doesnt have enough intermediary bits such that to be unique - not an ULA

There are a number of problems with this theory. First, if you don't see the parallels between this line of thinking and the reason that every application on the internet runs over TCP/80 or TCP/443 regardless of the application layer protocol these days, then you aren't paying attention.

However, in more detail:

1. What makes you think that an administrator that didn't read the original RFC would
	read and heed this additional document?

2. The next logical thing is that they all move to fd01::1/64. Do we keep publishing
	documents until we run out of easy to remember ULA addresses?

The need here isn't to change the administrator's behavior because we don't like the outcome. The need here is to recognize that administrators live and work in the real world where they have enough complexity in their lives without adding very large random numbers to their daily routine. Having prefixes which are easy to remember has value to them and no amount of effort to tell them to make their lives more difficult with little or no perceived immediate benefit is not likely to be readily accepted by them.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 21 Mar 2013 09:43:36 -0500

> This ULA-5 requirement is wrong and shouldnt be there - neither for CPEs

I disagree... ULA-5 is an important safeguard. If you want to build a large
home-to-home network, do it with GUA, ULA is poorly suited to the task.

> has no connection to Internet.

That's worked out so well in Japan so far.... NOT!

> concentrates the many routes only in a few-places - the DFZ.

This is not a bad thing. If you want to scale a network to large size, then either use GUA or expect to have to put some effort into the routing process.

ULA-5 does not prevent the router from being a default router. It prevents the router from advertising itself as a default router via RA packets.

It can still advertise an OSPF default, BGP default, and/or participate in VRRP.

We should, in all cases, avoid doing things that are damaging to GUA-based installations for the sake of making ULA work better for fringe cases.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 21 Mar 2013 09:53:08 -0500

> Small Client PC == little memory, long search time.

I'm sorry, but let's move back to the real world for a moment.

My raspberry PI has more memory and can probably do route lookups faster than most of the home-routers that are on the market today. The scale problem here isn't on the client PCs being able to handle ≤1000 prefixes, it's in the CPE routers being unable to handle ≥ 32 prefixes or so in most cases. Since your default route proposal would still require all of the CPE routers to carry all of the ULA routes and not use a default, it fails in the real world.

> to store a single default route.

$35 Client PC = 1000s of routes workable with reasonable forwarding speeds.
$60 CPE Router = Can't handle 100s of routes, let alone 1000s.

But thanks for playing.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 21 Mar 2013 10:05:31 -0500

Sent from my iPad

> people to process them, which means higher cost.

Every RIR does a lot of things besides processing registrations. Yes, the COGS per request would probably remain fairly constant... Increased workload = more employees and costs there scale roughly linearly with requests. However, the costs of outreach, meetings, list administration, DNS server maintenance, etc. all remain relatively fixed and increasing the number of entities by which those numbers are divided will inherently lower the cost per organization.

> trust the LIR on this and automatically give out PI assignments up to a

That might be valid way to further reduce costs.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 21 Mar 2013 10:14:17 -0500

> Enterprise to one or several Providers.)

This explains a lot...

> second and too large routing table entries.  Isnt't there a risk like that?

Right... For the latter, MIP is probably a better solution than BGP.

> ?  Is this something specified in the address?  (I heard of prefix

Not really. (I don't know what you actually mean by prefix coloring).

If you get a prefix from an ISP, it is most likely non-portable. The ISP will let you use the
prefix as long as you are connected to them, but when you disconnect from them, you must stop using the prefix.

If, OTOH, you get the prefix from an RIR or other non-ISP LIR or NIR, then probably it is "portable" meaning you can connect and disconnect from ISPs that will accept your advertisement of said prefix into their routing tables and forward said advertisement to other autonomous systems on your behalf.

> Right... we've seen experiments of BGP with planes, and of other

Yep... I expect we'll see a lot more of this in the future.

>> relationships. Perhaps even a combination of BGP and MIP.

Not so new. I've been multihomed using BGP at home for more than a decade.

> area of mobility like continents).

So what? If they're non-connected (and ULA would be non-connected and equally topologically incorrect), what's the difference?

> to which to tunnel.  If there's not such Anchor then there's no GUA

My point is that GUA is equally possible and workable to ULA. The only difference in that case is that with ULA, there's no hope of ever making those addresses connected by any means. With GUA, you may be unable to do so practically, but at least you have various options which you can try.

> Churn - these vehicular networks are not as large as the Internet (will

What difference does it make in the disconnected case that you use ULA instead of GUA? What advantage do you perceive from the ULAs in that context?

> - yet not to the Internet at large.

What, exactly, are you gaining from this additional unnecessary complexity?

> which are sure to be unique enough witin that site.

This question is identical whether one uses ULA or GUA for this purpose.

> It's not a question of ULA vs GUA.

That may not be your current question, but it is most certainly the question applicable to the issues I was raising.

Owen

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Mar 2013 15:26:59 +0000

On 21/03/2013 14:43, Owen DeLong wrote:
...
> It can still advertise an OSPF default, BGP default, and/or participate in VRRP.

Absolutely. And certainly we should assume that a sophisticated home network,
with or without peer connections to the neighbours, would be running a
routing protocol.

> We should, in all cases, avoid doing things that are damaging to GUA-based installations for the sake of making ULA work better for fringe cases.

On this we agree. Since ULAs were designed to behave exactly like GUAs except for
not being routed on the Internet, it really is a matter of getting the address
selection preferences right. (I don't mean to say that is a done deal today.)

   Brian

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 21 Mar 2013 16:38:47 +0100

Le 21/03/2013 16:26, Brian E Carpenter a écrit :
> On 21/03/2013 14:43, Owen DeLong wrote: ...
>> ULA-5 does not prevent the router from being a default router. It
>> prevents the router from advertising itself as a default router
>> via RA packets.
>>
> Absolutely. And certainly we should assume that a sophisticated home
> network, with or without peer connections to the neighbours, would
> be running a routing protocol.

Yes, routing protocol between CPEs if needed, or other form of informing
each other about one home's prefix.

But the Client PC iPads aren't likely to run OSPF BGP VRRP.  How else to
inform the address of the default router to these Client PCs?

>> We should, in all cases, avoid doing things that are damaging to
>> GUA-based installations for the sake of making ULA work better for
>> fringe cases.
>
> On this we agree. Since ULAs were designed to behave exactly like
> GUAs except for not being routed on the Internet, it really is a
> matter of getting the address selection preferences right. (I don't
> mean to say that is a done deal today.)

Ok.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 21 Mar 2013 17:16:21 +0100

Le 21/03/2013 15:33, Owen DeLong a écrit :
>>>>> What worries me is that in non-zeroconf environments, or
>>>>> those where manual override is possible, administrators will
>>>>>  use fc00::/48, as it's easier to type/remember.
>>>>
>> In a sense yes, but what better could one do? DEsign a better way
>> to generate this uniqueness? There are ways for that, like starting
>> from truly unique application-specific immutable IDs which hardly
>> ever experienced collisions (like MAC-based did).
>
> As I said at the time ULA was discussed,

YEs, at that time someone put up a public automated registry... is it
still up?

> the best thing would have been to recognize GUA as a preferable
> alternative and make better provisions for GUA to be used for
> disconnected networks.

But that's an ULA - it is a particular set of addresses in the total
space of IPv6 addresses which are to be used for disconnected networks -
your wish was realized.

> Unfortunately, at this point, that ship has sailed. Now it boils down
> to limiting the damage done by ULA. To do that, we need to recognize
> that ULA can and will be deployed stupidly in spite of the warnings
> in the ULA RFCs.

I prefer education, not sure how else to limit damage.  Actually I think
ULA is not damage - we need them; and I think the very act of limiting
something by killing some draft is not constructive.

> As a result, we should avoid creating additional RFCs which depend
> on ULA not being deployed stupidly and make sure, instead, that
> future RFCs are designed with this expectation in mind.
>
>> There could be ways to be less idealistic and yet come up with
>> unique ULAs in certain contexts.
>
> Sure, but we can't rationally depend on that happening in all cases
> which is what you were proposing in claiming that there is "much
> hope".

A case could be particular site.  We may define the Border Router of
that site, and the ULA generation algorithm for that site.

>>> statistically high probability of uniqueness for those who
>>> deploy ULA according to the RFC. Even there, there is no
>>> guarantee of any level of uniqueness, just a strong probability.
>>
>> I think this statement assumes exclusively the suggested ULA
>> generation algorithm in the RFC. But better algorithms could be
>> made which remove that probability factor, in certain contexts.
>
> OK, so now I'm confused. First you argue that the ULA RFC as is
> provides uniqueness and we can ignore the fact that it won't be
> reliably implemented per the RFC.

Let me explain: the ULA generation algorithm given as an example in that
RFC has some uniqueness properties.  E.g. its uniqueness depends much on
the EUI-64 (in addition to time and SHA randomness).

When one complains that may not be unique enough, then immediately one
thinks that algorithms may be improved to give better uniqueness.  E.g. 
if one worries uniqueness of EUI-64 then there exist other addressing 
spaces whose uniqueness is much more likely - the space of fingerprints.

If we had a better ULA generation algorithm - based on fingerprints, not
on EUI-64 - then we could be safer on the uniqueness side of ULA.

But the task may be easier than that.  One wouldn't look at global 
uniqueness, but maybe at uniqueness in a domain of activity, or maybe in 
a site.

If we look at uniqueness within one particular site, then it's even 
easier to do better-than-EUI-64 uniqueness.  Take that site's example 
addressing space (e.g. its phone numbers - they're all unique within 
that site) and put them in ULA - it's guaranteed unique in that site.

> Now you're arguing that violating the RFC is an even better way to go
> so that we can get guaranteed uniqueness?

No, defining new ULA generation algorithms is not violating that RFC. 
That RFC gives one example algorithm of ULA generation algorithm (it 
says so 'example') so other examples _are_ possible.

> It is precisely the tendency for ULA discussions to spiral into tight
> little circles like this that convinces me that ULA is a quagmire
> which causes many more problems than it solves.

IT's not a quagmire.  There are ways forward.

>>> However, the probability that the majority of administrators
>>> will even read the ULA RFC (how many people do you think have
>>> actually read RFC-1918 vs. the number that have deployed 10/8 or
>>> any other RFC-1918 address? I'll give you a hint... Ask a bunch
>>> of administrators which of the following are RFC-1918 addresses.
>>> If it's not an open book test, I bet the results surprise you.
>>
>> I agree in a sense, I let myself surprised by that. But things
>> could be done about it.
>
> Such as?

Such as defining various particular contexts: homenet, vehiculars were 
mentioned, and for each of those contexts describe a likely method 
already in use to use ULAs together with the limit of that site.

>>> 172.30.19.6        About half will get this wrong. 172.32.99.7
>>> The other half will get this wrong. 172.80.15.7        About half
>>> of the ones that got the previous question wrong will also get
>>> this one wrong.
>>
>> I got them all wrong at a quick view.  I'd have to read the RFC1918
>> and find the prefix length of the 172. private addresses to do it
>> right. Fortunately there's that RFC.
>
> Yes, but how many of the IT professionals running IPv4 RFC-1918
> addressed networks even know the number? How many of those have
> actually read the RFC? (If it's more than 5% I would be very
> surprised). Do you have any idea how many people I talk to that still
> say "RFC-1597?"

Right...

>>>> (if one just tries to just try quickly ifconfig add fd::1/64
>>>> then it's probably not according to the RFC, which would want
>>>> more digits there.)
>>>

So to stimulate sysadmins just a little bit, we could write that:

fd::1/64   is a highly probable GUA   - HP GUA
fd00::1/64 is a highly improbable ULA - HI ULA

>> Let's put that in a document! State upfront that sysadmins should
>> not assign fd00::1/64 on any interface (be that default or not)
>> because it doesnt have enough intermediary bits such that to be
>> unique - not an ULA by RFC.
>
> There are a number of problems with this theory. First, if you don't
>  see the parallels between this line of thinking and the reason that
>  every application on the internet runs over TCP/80 or TCP/443
> regardless of the application layer protocol these days, then you
> aren't paying attention.
>
> However, in more detail:
>
> 1. What makes you think that an administrator that didn't read the
> original RFC would read and heed this additional document?

I dont know.  Right...

> 2. The next logical thing is that they all move to fd01::1/64. Do we
>  keep publishing documents until we run out of easy to remember ULA
> addresses?

Right...

> The need here isn't to change the administrator's behavior because we
> don't like the outcome. The need here is to recognize that
> administrators live and work in the real world where they have enough
> complexity in their lives without adding very large random numbers to
> their daily routine. Having prefixes which are easy to remember has
> value to them and no amount of effort to tell them to make their
> lives more difficult with little or no perceived immediate benefit is
> not likely to be readily accepted by them.

Ok, but please dont write documents in which you kill ULAs.

(like when killing fec0:: site-local)

Alex

---

From: Owen DeLong <[email-masked]>
Date: Thu, 21 Mar 2013 11:22:56 -0500

> inform the address of the default router to these Client PCs?

RIO

Owen

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 21 Mar 2013 17:30:45 +0100

Le 21/03/2013 15:43, Owen DeLong a écrit :
> I disagree... ULA-5 is an important safeguard. If you want to build
> a large home-to-home network, do it with GUA, ULA is poorly suited
> to the task.

Ok, after some illuminating emails I can agree to that.

But there too - keep that ULA-5 a Home only requirement.  It doesnt
apply everywhere.

> That's worked out so well in Japan so far.... NOT!

Not sure what you refer to...

> This is not a bad thing. If you want to scale a network to large
> size, then either use GUA or expect to have to put some effort into
> the routing process.

There is an intermediary between one home-only space and GUA which is
the total space.

At the very least, one may wonder why not ULA in a home be able to talk
to ULA in that ISP?  Firmware update from ISP to CPE can easily happen
with ULA.

> prevents the router from advertising itself as a default router via
> RA packets.

How else can it do it in a way which a Smartphone is likely to
implement? (other than RA which seems forbidden).
> It can still advertise an OSPF default, BGP default, and/or

Ok - none is implemented by a Smartphone.

> GUA-based installations for the sake of making ULA work better for

That is the first worry - right!  First, do no harm to GUA.  But I am
optimistic because I see much hard work done to avoid harming GUA.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 21 Mar 2013 17:45:40 +0100

>> inform the address of the default router to these Client PCs?

Router Information Option of RFC4191?  But that relies on the fact that 
that the Router Lifetime is 0 in the RA, which seems forbidden by the 
CPE rfcbis draft.

or am I missing something?

Alex

---

From: Owen DeLong <[email-masked]>
Date: Thu, 21 Mar 2013 11:45:33 -0500

> YEs, at that time someone put up a public automated registry... is it
At the time, there were at least a dozen registries created. The most popular was probably the one at SIXXS. I don't know if any of them are still running or not. To me, they seemed antithetical to the purpose of ULA-Random, an effort to circumvent the lack of consensus around ULA-Registered.

> space of IPv6 addresses which are to be used for disconnected networks -

No, it wasn't. Now, instead of just using GUA for everything and being able to decide on a case-by-case basis and dynamically change that decision as circumstances change, we have, instead, restored this absurd dichotomy and created unnecessary artificial semantics around particular ranges of numbers.

> something by killing some draft is not constructive.

I'm all for education. However, given our success rate with education in the
RFC-1918 world of IPv4, I'm also going to be realistic in realizing that education
will often fail to penetrate in the real world.

As to the latter, I think that depends very much on the draft. In many cases, limiting things by killing some drafts is exactly the right thing to do. Think how much of the confusion and consternation in the current discussion could have been avoided if we'd just done that with the original ULA draft.

> that site, and the ULA generation algorithm for that site.

Not sure how this would address my statement.

We cannot count on the idea that every site will correctly implement ULA.

Just because you think we might be able to control that in some limited set of cases doesn't change the fact that it will never be universally true. Ergo, a draft which depends on universal correct implementation of ULA is, IMHO, a non-starter.

> the EUI-64 (in addition to time and SHA randomness).

It's not that I don't understand how this works. It's that I oppose inaccurate claims about what capabilities that provides.

> thinks that algorithms may be improved to give better uniqueness.  E.g. if one worries uniqueness of EUI-64 then there exist other addressing spaces whose uniqueness is much more likely - the space of fingerprints.

I didn't say it wasn't unique enough. I said it wasn't guaranteed uniqueness, but rather mathematically likely uniqueness.

> on EUI-64 - then we could be safer on the uniqueness side of ULA.

Actually fingerprints are statistically less likely to be unique than the current ULA algorithm. Please actually research your claims before making them.

> But the task may be easier than that.  One wouldn't look at global uniqueness, but maybe at uniqueness in a domain of activity, or maybe in a site.
> 
> If we look at uniqueness within one particular site, then it's even easier to do better-than-EUI-64 uniqueness.  Take that site's example addressing space (e.g. its phone numbers - they're all unique within that site) and put them in ULA - it's guaranteed unique in that site.

I'm not sure how you would propose to achieve better-than-64-bit uniqueness in a 40 bit address space. Even the current algorithm does not pretend to do that. It just uses EUI-64 as one of the inputs into the entropy in generating the random 40 bits.

> No, defining new ULA generation algorithms is not violating that RFC. That RFC gives one example algorithm of ULA generation algorithm (it says so 'example') so other examples _are_ possible.

Your earlier argument was that administrator assigning an address that wasn't chosen according to that algorithm (e.g. fd00::/64) was an RFC violation. Now you're saying that other algorithms are acceptable. Which is it?

(Pick the first one may be a bad algorithm, but it is an example of a different algorithm).

> IT's not a quagmire.  There are ways forward.

There are ways forward in a quagmire, but they are difficult. ULA makes things unnecessarily difficult. To wit, this entire discussion.

> Such as defining various particular contexts: homenet, vehiculars were mentioned, and for each of those contexts describe a likely method already in use to use ULAs together with the limit of that site.
> 

It is unclear to me how defining additional things in more documents will solve the problem that people don't read the existing documents.

> fd00::1/64 is a highly improbable ULA - HI ULA

And?

> Ok, but please dont write documents in which you kill ULAs.

Why not? Killing ULA would be a very good thing, IMHO. Nothing you have said so far convinces me otherwise.

> (like when killing fec0:: site-local)

Personally, I thought site-local made much more sense than ULA.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 21 Mar 2013 11:52:23 -0500

Sent from my iPad

> But there too - keep that ULA-5 a Home only requirement.  It doesnt

Yeah, actually, it should. Since it is a requirement for how routers are built, one cannot predict where a router will be deployed at the time the router is built for one thing.

> Not sure what you refer to...

Study the situation in Japan with IPv6 deployment involving NTT and their walled-garden IPv6 TV content delivery system.

It would really help this discussion if you made yourself aware of some of the history and the current context in which these issues are being considered.

> There is an intermediary between one home-only space and GUA which is

You are misunderstanding the concepts involved here rather substantially.

> to ULA in that ISP?  Firmware update from ISP to CPE can easily happen

Or one may wonder what possible advantage ULA offers in that circumstance over GUA?

> implement? (other than RA which seems forbidden).

RA is not forbidden. Default route via RA is forbidden. RIO via RA is perfectly fine.

> Ok - none is implemented by a Smartphone.

Who cares? If you use VRRP, the smartphone doesn't have to implement it. The smart phone can be given a static default to the VRRP address.

Ideally, we fix DHCPv6 and add the ability to provide routing information options in DHCPv6 as well.

> optimistic because I see much hard work done to avoid harming GUA.

Or we could use GUA and avoid all the hard work and the harm.

Owen

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 21 Mar 2013 18:17:13 +0100

Le 21/03/2013 17:52, Owen DeLong a écrit :
>>>>> whenever all of its configured and delegated prefixes are
>>>>> ULA prefixes.
>>>>
>>> I disagree... ULA-5 is an important safeguard. If you want to
>>> build a large home-to-home network, do it with GUA, ULA is
>>> poorly suited to the task.
>>
> Yeah, actually, it should. Since it is a requirement for how routers
> are built, one cannot predict where a router will be deployed at the
> time the router is built for one thing.

Right.

> Study the situation in Japan with IPv6 deployment involving NTT and
> their walled-garden IPv6 TV content delivery system.

Ok.
[...]
>> At the very least, one may wonder why not ULA in a home be able to
>> talk to ULA in that ISP?  Firmware update from ISP to CPE can
>> easily happen with ULA.
>

Maybe not much.

> RA is not forbidden. Default route via RA is forbidden. RIO via RA

But, the CPE rfcbis says that the Router Lifetime must not be greater
than 0.  There is no other way in which an RA can tell a Host it's a
default router than setting that lifetime to greater than 0.

Any RIO in an RA with a Router Lifetime greater than 0 can not make a
default route at the Host.

Or am I missing something?

(this is for curiosity only - as long as it stays as a CPE matter this
may not be that important to other contexts).

> Who cares? If you use VRRP, the smartphone doesn't have to implement
> it. The smart phone can be given a static default to the VRRP
> address.

Oh... but such advice may read to non-CPE operators (e.g. cellular
operators) that any other typical  IPv6 parameter could be hardcoded to
a certain VRRP'ed address.  Read - smartphones hardcoded with the IPv6
DNS Resolver address, because many reasons and the above included.

Clearly this should stay CPE.

> information options in DHCPv6 as well.

That sounds like a good idea - it deserves a separate thread.  I think
that coupling address auto-configuration with routing is desirable.

I am not sure whether you are aware, but the DHCPv6 route-options
discussions is stalled right now.  There are few private emails and
maybe an email list would get set up about DHCPv6 and route-options:
route-options, src-based routing and why not defrouter.

Or maybe we should discuss it here as well.

>>>  GUA-based installations for the sake of making ULA work better
>>> for fringe cases.
>>
>> That is the first worry - right!  First, do no harm to GUA.  But I
>> am optimistic because I see much hard work done to avoid harming
>> GUA.
>

YEs maybe; but GUA in vehicular moving networks and without Home Agent
can not work.

Killing ULA and requesting GUA without a HA may lead to NAT66 as well,
which is supposedly another evil.

I will not he unhappy if the recommendation is GUA+MobileIP but there
are people who claim HA is a single point of failure.

Alex

---

From: Owen DeLong <[email-masked]>
Date: Thu, 21 Mar 2013 14:34:55 -0500

> default router than setting that lifetime to greater than 0.

If the router doesn't provide internet access, it SHOULD NOT advertise
itself as a default router. That is the point. You are determined to argue
against that point, but the correct behavior is to NOT BE a default router
if you do not provide internet access.

Correct.

> Or am I missing something?

Yes… You are missing the fact that a collection of networks not attached
to the internet using ULA should use more specifics and not default routes.

> may not be that important to other contexts).

It is, actually, because you can't tell at manufacture time how a router will
be used, so you have to consider all possible use contexts of the router when
deciding how it should behave, and especially how it should behave by default.

> Clearly this should stay CPE.

We're not talking about hard coding anything. We're talking about static
configuration.

I don't know about smart phones in general, but I do know that whatever I
statically configure into my phone is specific to a given connection, e.g. part of the
definition for a particular wifi SSID, etc.

Phones can have different "personalities" to provide different sets of parameters
and static settings for different operational contexts.

> that coupling address auto-configuration with routing is desirable.

tt has a separate thread.

> Or maybe we should discuss it here as well.

No, we really shouldn't. At least not as part of this thread. Yes, I am aware
of the situation with DHCPv6 routing options. My point isn't to rehash that
discussion here (which I don't think most list participants would appreciate),
but to point out that the correct place to solve certain problems is somewhere
other than in this thread.

> YEs maybe; but GUA in vehicular moving networks and without Home Agent

Why does "without home agent" suddenly come into play?

You still are missing the point. If I use unrouted prefix 2001:1610:53ac::/48
in the vehicles in the exact same manner as I would use unrouted prefix
fd01:9c83:1ac0::/48, then there is no difference in the behavior or the impact
of the two prefixes. There is no change in the strain on the routing system.
There is no problem caused for anyone. The two prefixes have identical
semantics and usage and identical impact on the routing table.

> which is supposedly another evil.

How does GUA require NAT66 where ULA would not? You make no sense
here.

> are people who claim HA is a single point of failure.

You are assuming that all GUA must be globally routed. I'm talking about using
GUA prefixes exactly as one would use ULA. I'm not necessarily talking about
providing them with global reachability or anything else that they would not get
with ULA. I'm just talking about the fact that for private use on a disconnected
network, there is no actual technical advantage to ULA vs. GUA.

Owen

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 21 Mar 2013 20:40:50 +0100 (CET)

On Thu, 21 Mar 2013, Owen DeLong wrote:

> itself as a default router. That is the point. You are determined to 
> argue against that point, but the correct behavior is to NOT BE a 
> default router if you do not provide internet access.

So if the host doesn't support RIO then there won't be reachability for 
ULAs between LANs within the home. Correct?

I tried to make my home Cisco router send RIO for testing but I was unable 
do to do so (I believe, at least no more-specific route showed up on my 
Linux machine which is running 3.2). Anyone happen to know how this would 
be configured and how it would show up in the config?

---

From: joel jaeggli <[email-masked]>
Date: Thu, 21 Mar 2013 15:11:36 -0700

> effectively a few hundred IPv4 PI prefixes moving around at almost Mach 1.
iirc there were complaints that it was a relatively bad idea. there were 
no complaints as far as I know due to impact of the rate of prefix churn 
which was way lower (by orders of magnitude) than the worst offendors 
out there at the time. The prefix advertisement and withdrawal was in 
fact done by the groundstatations not the aircraft.

There were never hundreds of of transcontinental commercial aircraft 
engaged in  roaming on the service (there were around 200 planes total 
with the equipment). There are many more aircraft today operating with 
satellite or terrestrial internet connectivity and without such behavior.
> that increasing from 30k to millions of PI prefixes will work smoothly.
PA prefixes count the same as far as fib slots go and if they're 
multihomed by customers they're rather hard to aggregate.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 22 Mar 2013 09:14:32 +1100

In message <[email-masked]>, Owen DeLong writes:
> >> Without those flags, it is unlikely that it would have made multiple =3D
> >> IPv6 attempts before falling back to IPv4, but, rather would have made =3D=
> 
> >> one IPv6 attempt, then upon getting the unreachable, immediately try =3D
> >> IPv4.
> >>=20
> >> Owen
> >=20
> > % cat /etc/ip6addrctl.conf=20
> > #Prefix                          Prec Label    =20
> > ::1/128                           50     0
> > ::/0                              40     1    =20
> > 2002::/16                         30     2       =20
> > ::/96                             20     3       =20
> > ::ffff:0.0.0.0/96                 35     4       =20
> > fd92:7065:b8e::/48                45     5=20
> > fc00::/7                          5      6
> >=20
> 
> Remind me where I configure the router to send the contents of ip6addrctl.co=
> nf down to the SLAAC client... Oh, right...
> 
> Owen=

draft-ietf-6man-addr-select-opt-08.txt

You can do this by hand today.

I can configure my dhcp servers and clients to sent this using
options 224...254 today.  When the option code is assigned by IANA
I can change then to use that.

Built in support had been requested, so the operator doesn't have
to describe the option, just populate its values.  This is waiting
on IANA to do the assignment of the option code amongst other things.

When doing the internal request we found bugs in the draft which I
believe have now been fixed.

Mark

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 21 Mar 2013 22:46:55 +0000

> joel jaeggli
> Sent: Thursday, March 21, 2013 3:12 PM
> To: Brian E Carpenter; Alexandru Petrescu
> Cc: [email-masked]

This all happened before my time at Boeing, but my understanding
is that someone noticed prefixes being announced and withdrawn
due to aircraft mobility and brought the situation to light. Other
factors than this were behind Boeing's decision to get out of the
business, but the service itself lives on (minus the routing churn
problem) in current-day deployment.

Fred
[email-masked]

---

From: james woodyatt <[email-masked]>
Date: Thu, 21 Mar 2013 15:58:01 -0700

On Mar 21, 2013, at 09:22 , Owen DeLong <[email-masked]> wrote:
> On Mar 21, 2013, at 08:38 , Alexandru Petrescu <[email-masked]> wrote:
>> 

RFC 4191 Route Information Options (RIO) are not processed by OS X or iOS hosts.

--
james woodyatt <[email-masked]>
core os networking

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 21 Mar 2013 23:08:22 +0000

FWIW, Tony Hain and I worked on a document that seems closely
related to this subject about 10 years ago. This was before
the publication of ULA, and intended to help the process along.
I mention it in case it might offer some useful background to
these discussions (see below):

Fred

http://datatracker.ietf.org/doc/draft-hain-templin-ipv6-localcomm/
Abstract:
The IPv6 addressing architecture specifies formats for unicast addresses,
but provides no operational guidelines for their use. There is a clear
need for IPv6 to support organizational-scope communications whether
members of the organization are located in the same site or different
sites. Aspects of certain types of sites introduce challenges for supporting
organizational-scope communications. Of special interest are nomadic sites,
e.g., sites that are intermittently-connected or disconnected from the global
Internet, sites that frequently change provider points of attachment, sites
that temporarily or permanently merge with other sites, etc. This memo will
discuss scenarios and goals for IPv6 support organizational-scope communications.

---

From: joel jaeggli <[email-masked]>
Date: Thu, 21 Mar 2013 16:10:28 -0700

On 3/21/13 3:46 PM, Templin, Fred L wrote:
> due to aircraft mobility and brought the situation to light.
Ben Abarbanel from boeing presented it at nanog 31 yeah.

http://www.nanog.org/meetings/nanog31/presentations/abarbanel.pdf

and about a year later at the ietf 62 technical plenary.

some papers were published,  etc.

http://quark.net/docs/Global_IP_Network_Mobility_using_BGP.pdf
>   Other
yes as do other services with similar goals, in support of commercial 
aviation, general aviation, maritime, military and so forth.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 21 Mar 2013 23:20:18 +0000

> aviation, general aviation, maritime, military and so forth.

I didn't say there weren't other services. Passengers on many
or perhaps even most domestic flights in the US can enjoy
in-flight Internet based on cellular or SATCOM. Air traffic
control and airline operations are a different story, where
safety-of-flight is a mildly important consideration.

Fred

---

From: Owen DeLong <[email-masked]>
Date: Thu, 21 Mar 2013 18:57:58 -0500

On Mar 21, 2013, at 2:40 PM, Mikael Abrahamsson <[email-masked]> wrote:

>> If the router doesn't provide internet access, it SHOULD NOT advertise itself as a default router. That is the point. You are determined to argue against that point, but the correct behavior is to NOT BE a default router if you do not provide internet access.
> 
> So if the host doesn't support RIO then there won't be reachability for ULAs between LANs within the home. Correct?
> 

If you have a problem with a host which does not correctly implement the RFCs, get the host fixed.

Do not break other things in other areas for the sake of this fringe case.

> I tried to make my home Cisco router send RIO for testing but I was unable do to do so (I believe, at least no more-specific route showed up on my Linux machine which is running 3.2). Anyone happen to know how this would be configured and how it would show up in the config?

I don't know how to help you operate your equipment. I use different equipment. However, even if it is not possible with your equipment, see above.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 21 Mar 2013 18:59:44 -0500

> You can do this by hand today.

Bzzt… Non-starter for grandma.

> I can change then to use that.

Bzzt… Granny isn't going to be configuring complex options on a DHCP
server either.

> on IANA to do the assignment of the option code amongst other things.

Which will then be waiting on the vendors to implement which will then be
waiting on granny to update her router…

Right…. We might see this in my lifetime, but I'm not optimistic.

Owen

---

From: Mark Andrews <[email-masked]>
Date: Fri, 22 Mar 2013 11:11:14 +1100

In message <[email-masked]>, Owen DeLong write
s:
> > Why is there no hope? You're effectively saying that the ULA specifications
>  won't ever be followed correctly, rather than far more often than not. Could
> n't the same be said about any and all specifications? Why would people follo
> w nearly all specifications correctly, with the ULA specification being the s
> pecial case where they won't?
> 
> However, there is an important distinction to consider here. Most specificati
> ons are to be understood and implemented by protocol developers putting those
>  implementations into products. In the case of ULA, you're now talking about 
> the need for a site administrator to follow the specification, In my experien
> ce, there is a very wide range in terms of experience, capability, and motiva
> tion within this group, but it is overwhelmingly weighted towards the low end
>  (unmotivated, not very experienced, and unlikely to even read an RFC vs. tak
> e their buddy's advice that "fd00::/8 for IPv6 works just like 10/8 for IPv4"
> .

Actually I expect most ULA prefixes to be generated by CPE devices.
 
Use ULA on/off with a pre-filled in, CPE generated, ULA field that
is greyed out when set to off.  If the field is over written it is
saved to non-volatile memory.  For good measure fd00::/48 is rejected.

You can override it but it starts out as a random prefix.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 22 Mar 2013 04:30:41 +0100 (CET)

> RFCs, get the host fixed.

I have little problem with broken intra-home connectivity if the Internet 
link is down. I just want to know that deploying a rfc6204bis home router 
won't cause people to call my customer support and complain about "slow 
Internet" because the customer doesn't have IPv6 Internet connectivity 
(but IPv4 works). It seems this is not a problem, so I'm happy.

So in this ULA usage analysis document it should be noted that a routed 
home with ULAs won't work until the hosts support RIO.

> I don't know how to help you operate your equipment. I use different 
> equipment. However, even if it is not possible with your equipment, see 
> above.

Do you know of any equipment that actually supports RIO?

---

From: Owen DeLong <[email-masked]>
Date: Thu, 21 Mar 2013 22:52:35 -0500

On Mar 21, 2013, at 10:30 PM, Mikael Abrahamsson <[email-masked]> wrote:

> I have little problem with broken intra-home connectivity if the Internet link is down. I just want to know that deploying a rfc6204bis home router won't cause people to call my customer support and complain about "slow Internet" because the customer doesn't have IPv6 Internet connectivity (but IPv4 works). It seems this is not a problem, so I'm happy.
> 
> So in this ULA usage analysis document it should be noted that a routed home with ULAs won't work until the hosts support RIO.
> 

I'm all for that.

> Do you know of any equipment that actually supports RIO?

I haven't done such an analysis as it hasn't been important until now. I've avoided the use of ULAs which helps a lot.

Owen

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Mar 2013 08:45:49 +0000

> RFC 4191 Route Information Options (RIO) are not processed by OS X or iOS hosts.

RIPng?

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Mar 2013 08:49:37 +0000

> multihomed by customers they're rather hard to aggregate.

Of course. The discussion here was about PI instead of ULA, however.
The point is that ULA prefixes can and should be filtered, but that
is not the expectation for PI.

   Brian

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 22 Mar 2013 02:10:33 -0700

> RFC 4191 Route Information Options (RIO) are not processed by OS X or iOS

Can that be fixed, or is there some fundamental objection to RIOs (like
there is to making the getaddrinfo policy table configurable) that makes it
unrealistic to assume that these will be supported in the future?

If you don't support RIOs, then there is no way to tell hosts that there
are specific routes, so networks that want any connectivity at all are
forced to give them a default route, even if there is partial connectivity.
That seems unfortunate.

---

From: Merike Kaeo <[email-masked]>
Date: Fri, 22 Mar 2013 02:42:59 -0700

> http://quark.net/docs/Global_IP_Network_Mobility_using_BGP.pdf

Connexion By Boeing peaked my interest since I worked for them and back in 2005/6 developed their
IPv6 strategy plus configured the testbed ground stations to be dual-stacked (I had a /48 from Boeing's 
/32 PI routed by NTT....that caused quite the debates internal to NTT since at that time ISPs were still debating 
merits of doing so).    It was fun trying get the ISPs to tell me the real deal... "no, I don't want a tunnel I want a 
native eBGP connection and please route my /48".  How times change.

I can definitively state that at that time with v6 there was going to be NO ULA usage although yes, there was
routing churn that was disliked by ISPs but noone was actively saying it was causing *great harm*.  It was just
very unsavory - hence the talks at NANOG and APRICOT and RIPE to explain and get more feedback. [and the folks
building the routing had talked to some global ISPs before finally deciding on going that route]

Of course using v6 routing at that time if we had gone live *could* have shown interesting global routing behavior :)  

It's unfortunate Connexion By Boeing went under....we were in process of moving to production test with v6
at the time (early 2006).    Although as Fred has stated, the system is still operational but for a very limited set of folks.
Stuck in v4 AFAIK.

As far as mobility scenarios - due to the routing churn issues in v4 I was following NEMO and other mobility scenarios
to see how they might be utilized with v6.  Not sure where that went as I stopped following it.

Whether you use ULA or GUA for mobility has no difference.  The issue comes in whether you have an entirely closed system 
(air traffic control and some other global mobile entities do) or whether you need to communicate to outside world.  The latter
gets more interesting with ULAs.

- merike

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 22 Mar 2013 15:26:23 +0000

Hi Merike,

> From: Merike Kaeo [mailto:[email-masked]]
> Sent: Friday, March 22, 2013 2:43 AM
> To: joel jaeggli
> Cc: Templin, Fred L; Brian E Carpenter; Alexandru Petrescu; [email-masked]
> >>>>> second and too large routing table entries.  Isnt't there a risk
> like
> >>> that?
> >>>> Well, it was three or four orders of magnitude smaller, but there
> were a
> >>> lot
> >>>> effectively a few hundred IPv4 PI prefixes moving around at almost
> Mach
> >>> 1.
> /32 PI routed by NTT....that caused quite the debates internal to NTT
> since at that time ISPs were still debating
> merits of doing so).    It was fun trying get the ISPs to tell me the real
> deal... "no, I don't want a tunnel I want a
> Of course using v6 routing at that time if we had gone live *could* have
> shown interesting global routing behavior :)
> 
> at the time (early 2006).    Although as Fred has stated, the system is
> still operational but for a very limited set of folks.
> Stuck in v4 AFAIK.

My understanding was that the service was picked up by
Panasonic eXConnect.
 
> As far as mobility scenarios - due to the routing churn issues in v4 I was
> following NEMO and other mobility scenarios

We have taken care of the routing churn issue with SEAL/VET/IRON:

https://datatracker.ietf.org/doc/draft-templin-intarea-seal/
https://datatracker.ietf.org/doc/draft-templin-intarea-vet/
https://datatracker.ietf.org/doc/draft-templin-ironbis/

Thanks - Fred

> Whether you use ULA or GUA for mobility has no difference.  The issue
> comes in whether you have an entirely closed system
> (air traffic control and some other global mobile entities do) or whether
> you need to communicate to outside world.  The latter

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 22 Mar 2013 17:30:17 +0100

Le 21/03/2013 20:34, Owen DeLong a écrit :
>> But, the CPE rfcbis says that the Router Lifetime must not be
>> greater than 0.  There is no other way in which an RA can tell a
>> Host it's a default router than setting that lifetime to greater
>> than 0.
>
> If the router doesn't provide internet access, it SHOULD NOT
> advertise itself as a default router. That is the point.

I shared that view at some point, but I changed.

The meaning of 'default' route is not necessarily Internet.  It means to
be used when everything else fails, that's all.  It is also a
high-availability feature - absence of a default route means the system
is less reliable.  One _wants_ a default option whenever one does
something with multiple choice.

There are many other networks using default routes and which don't
finally lead to Internet, now.  They will but later.

> You are determined to argue against that point, but the correct
> behavior is to NOT BE a default router if you do not provide
> internet access.

The default route could also lead to a certain path which is longer than
the shortest path to the Internet.  This is built in some protocols to
which nobody seems to object.

The alternatives to avoid that ('Route Optimization' == default route
point to the shortest path to the Internet) don't have much tract in the
Internet itself - people won't modify every other stack to make sure the
default route is the shortest path to the Internet - they accept if it
leads _somehow_ to the Internet.

Given that, I doubt one could say 'default route==Internet'.

> Yes… You are missing the fact that a collection of networks not
> attached to the internet using ULA should use more specifics and not
> default routes.

That specific routes will stop these networks from growing large.

>> (this is for curiosity only - as long as it stays as a CPE matter
>> this may not be that important to other contexts).
>
> It is, actually, because you can't tell at manufacture time how a
> router will be used, so you have to consider all possible use
> contexts of the router when deciding how it should behave, and
> especially how it should behave by default.
>
>>
>>> Who cares? If you use VRRP, the smartphone doesn't have to
>>> implement it. The smart phone can be given a static default to
>>> the VRRP address.
>>
>>  operators) that any other typical  IPv6 parameter could be
>> hardcoded to a certain VRRP'ed address.  Read - smartphones
>> hardcoded with the IPv6 DNS Resolver address, because many reasons
>> and the above included.
>>
> We're not talking about hard coding anything. We're talking about
> static configuration.
>
> I don't know about smart phones in general, but I do know that
> whatever I statically configure into my phone is specific to a given
> connection, e.g. part of the definition for a particular wifi SSID,
> etc.
>
> Phones can have different "personalities" to provide different sets
> of parameters and static settings for different operational
> contexts.

I am talking about operators who hardcode - pre-configure - the DNS
Resolver IPv6 address in each smartphone sold out, instead of automating
that configuration with things like DHCP or RA.  I complain about that.

(I have nothing against a geeky person personalizing her smartphone with
google's DNS Resolver IPv6 address, instead of the one given by the
operator).

>> That sounds like a good idea - it deserves a separate thread.  I
>> think that coupling address auto-configuration with routing is
>> desirable.
>

What is tt?

>> maybe an email list would get set up about DHCPv6 and
>> route-options: route-options, src-based routing and why not
>> defrouter.
>>
> No, we really shouldn't. At least not as part of this thread. Yes, I
> am aware of the situation with DHCPv6 routing options. My point isn't
> to rehash that discussion here (which I don't think most list
> participants would appreciate), but to point out that the correct
> place to solve certain problems is somewhere other than in this
> thread.
>
>>>>> We should, in all cases, avoid doing things that are
>>>>> damaging to GUA-based installations for the sake of making
>>>>> ULA work better for fringe cases.
>>>>
>>>> That is the first worry - right!  First, do no harm to GUA. But
>>>> I am optimistic because I see much hard work done to avoid
>>>> harming GUA.
>>>
>> YEs maybe; but GUA in vehicular moving networks and without Home
>> Agent can not work.
>>
>

Because that's how the planes Connexion did - without Home Agent, at a
certain experiment. (I think at some point also used HA, but the BGP
version may be without HA - HA is a MIP entity, BGP doesnt have HA).

Because some deployments of planes and other vehicles seem to not use
HA.  I'll post separately.

> You still are missing the point. If I use unrouted prefix
> 2001:1610:53ac::/48 in the vehicles in the exact same manner as I
> would use unrouted prefix fd01:9c83:1ac0::/48, then there is no
> difference in the behavior or the impact of the two prefixes.

There is some difference - with ULA prefix fd01:9c83:1ac0::/48 we
_could_ define a border precisely (tell who's the BR and what's the
generation algorithm).  With GUA 2001:1610:53ac::/48 we can't do it.

> There is no change in the strain on the routing system.

I agree.

That also means that there is no advantage on using GUA instead of ULA
in a vehicle.  The only reason we had to use GUA was if we could have
done route injection (BGP, etc.) from each vehicle to the Internet.  It
may be possible for planes, but impossible for vehicles for several
reasons - not the least being that a vehicle connects often with
cellular and cellular operators won't accept BGP from their UE clients.

> There is no problem caused for anyone. The two prefixes have
> identical semantics and usage and identical impact on the routing
> table.

Well I guess one would be allowed to inject GUA PI prefixes with BGP
from a plane, but would not be allowed to inject ULA prefixes with BGP
from the same plane.

>> Killing ULA and requesting GUA without a HA may lead to NAT66 as
>> well, which is supposedly another evil.
>

Well, if a vehicle can't use ULA then a vehicle must use GUA prefix
within.  Maybe provider-independent GUA, or maybe provider-assigned GUA.
  Then one is not allowed to inject the prefix at the attachment point.
So one has to use a Home Agent.

But there are people who think a Home Agent is a single-point of failure
(all vehicles must tunnel to that HA, otherwise no Internet - if HA down
then vehicles cant talk to Internet; and second - routes are
artificially long, the default route points to the HA even though the
Server of the vehicle is quite near - this is quantified problem).

At that point - if no ULA and no HA possible then one still needs to put
some addresses in that vehicle.  And the most straightforward way to do
that is NAT66 (ip6tables MASQUERADE kernel 3.something ok).  That is
independent of the kind of addresses within the vehicle - works with
fd::1/64 as well.

If one does that NAT66 then one reaches Internet straight - no
artificially long paths, no single point of failure HA, no ULA vs GUA
problem.

The one thing that could be against NAT66 is the typical anti-NAT
argument - reverse reachability.  But many apps in the vehicle today are
very exciting yet dont require that reverse reachability.  Other
arguments may exist.

So, if one would like to avoid NAT then one better allows ULAs...
(rather than forbidding them).

But let me ask one the following - suppose one grandma private person
ambitions to connect her own automobile to IPv6, without the
participation of the vehicle manufacturer and cell network in that
endeavor; the cell network simply provides a full IPv6 cellular
connection.  What addressing scheme would she use within the vehicle?

>> I will not he unhappy if the recommendation is GUA+MobileIP but
>> there are people who claim HA is a single point of failure.
>
> You are assuming that all GUA must be globally routed. I'm talking
> about using GUA prefixes exactly as one would use ULA.

At that point it is ok, but it implies several things.

First, one uses GUA in a vehicle but knows somehow they shouldn't be
routed to the Internet.  No RFC tells that, the person just knows.  I
doubt it possible.

Second, if one day one should connect that vehicle to the Internet, then
one would supposedly need _another_ set of GUA which _should_ be routed
to the Internet, typically with the help of the Home Agent.

At that point one may end up with two different sets of GUAs in the same
vehicle - one for non-Internet connection, and the other full Internet
connection.  This means that each PC in the vehicle has at least two
addresses (not to mention the link-local and privacy extensions one).
This brings in the src-based routing problem, or the src address
selection problem.

These src-based aspects are easier to describe if we talked ULA and GUA,
as opposed to talking GUA1 and GUA2.

It's easier to say - if the src address is ULA then do this, and if it's
GUA then do that.  Otherwise we'd have to say if src is a GUA which is
forbidden to be put on the Internet do this, otherwise do that.

> I'm not necessarily talking about providing them with global
> reachability or anything else that they would not get with ULA. I'm
> just talking about the fact that for private use on a disconnected

I can agree to that.

That doesn't mean ULA is not useful.

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Mar 2013 16:46:16 +0000

> something with multiple choice.

As I've said since the beginning of MIF, a host needs a default route
per source prefix. I think you'll find that solves the dilemma.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Fri, 22 Mar 2013 14:23:24 -0300

On 03/21/2013 05:41 AM, Lorenzo Colitti wrote:
> On Wed, Mar 20, 2013 at 8:01 PM, Mark Smith <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Yes. Their IPv6 router will generate an ICMPv6 destination
>     unreachable as it doesn't have a route matching the AAAA (i.e. a
>     default route). That will cause the browser to fall back to IPv4.
> 
> 
> Incorrect. RFC 1122, section 4.2.3.9 <http://4.2.3.9>: "Since these
> Unreachable messages indicate soft error conditions, TCP MUST NOT abort
> the connection".

You should be looking at RFC 5461.

And if you wonder why RFC 5461 doesn't formally update the specs, my
answer would be "politics!".

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Owen DeLong <[email-masked]>
Date: Fri, 22 Mar 2013 13:30:39 -0500

> per source prefix. I think you'll find that solves the dilemma.

No, it really doesn't. In fact, I would say that may well cause more problems than it solves.

Bottom line is that you should only provide a default route if you can reasonably expect to forward all traffic received via that default route. Otherwise, you are creating a black hole.

Routes are destination based, not source based, so a default route (route to everywhere on the internet) indicates that the next hop gateway has announced its intention to forward all traffic to any destination.

A router which has only ULA prefixes is utterly incapable of doing anything remotely resembling that, so it should not make a claim that it can in its RAs.

Owen

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 22 Mar 2013 19:53:03 +0100 (CET)

On Fri, 22 Mar 2013, Owen DeLong wrote:

> Routes are destination based, not source based, so a default route 
> (route to everywhere on the internet) indicates that the next hop 
> gateway has announced its intention to forward all traffic to any 
> destination.

I don't agree at all. A router will indicate to forward some traffic, some 
other might be dropped by uRPF upstream. So a default route should be 
coupled with whatever was provisioned by that router (ok, so I announced 
RA for a /64 prefix and default route, then this default route is only 
valid for that prefix).

I believe IPv6 was wrongly designed from the get-go in this aspect. 
Routing information and prefix annuncement should be coupled together, not 
separately. So src, dst and routing should belong together instead of 
being treated as separate the way it's done right now with routing, RA 
prefix announcement and address selection being completely separate 
entities.

> A router which has only ULA prefixes is utterly incapable of doing 
> anything remotely resembling that, so it should not make a claim that it 
> can in its RAs.

Well, this I can agree with though.

I also believe RIOs should be scoped, so basically a RIO should also have 
a source prefix in it's announcement. Src, dst, route. Together. This way 
a RIO could indicate that ULA should communicate with ULA and nothing 
else. If you don't have a ULA address, you can't send packet to ULA 
destinations.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Fri, 22 Mar 2013 19:01:33 +0000

>(route to

This is not true, strictly speaking, although most router implementations
look at only the destination IP header for deciding the next-hop in case
of unicast IP traffic. This is what we tend to refer to as the
"Destination based routing".

Routers can be implemented to look at the source IP header or both source
and destination IP headers for deciding the next-hop. Heck, routers can be
implemented to look at other fields (e.g. DSCP) in the IP header or not
even look at the IP header (and just look at the MPLS header).

http://tools.ietf.org/html/rfc791
//
  gateways in the internet system.  The datagrams are routed from one
  internet module to another through individual networks based on the
  interpretation of an internet address.  Thus, one important mechanism

//

Cheers,
Rajiv

-----Original Message-----
From: Owen DeLong <[email-masked]>
Date: Friday, March 22, 2013 2:30 PM
To: Brian Carpenter <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [v6ops] questions regarding
rfc6204bis	(draft-liu-v6ops-ula-usage-analysis)

>Bottom line is that you should only provide a default route if you can
>reasonably expect to forward all traffic received via that default route.
>Otherwise, you are creating a black hole.
>
>Routes are destination based, not source based, so a default route (route
>to everywhere on the internet) indicates that the next hop gateway has
>announced its intention to forward all traffic to any destination.
>

---

From: Owen DeLong <[email-masked]>
Date: Fri, 22 Mar 2013 15:10:47 -0500

On Mar 22, 2013, at 1:53 PM, Mikael Abrahamsson <[email-masked]> wrote:

> I don't agree at all. A router will indicate to forward some traffic, some other might be dropped by uRPF upstream. So a default route should be coupled with whatever was provisioned by that router (ok, so I announced RA for a /64 prefix and default route, then this default route is only valid for that prefix).

A router and routes are two different things. Here is an example of a routing table:

Routing tables

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
default            172.20.10.1        UGSc           25        0     en0
127                127.0.0.1          UCS             0        0     lo0
127.0.0.1          127.0.0.1          UH              2     6150     lo0
169.254            link#4             UCS             0        0     en0
172.20.10/28       link#4             UCS             1        0     en0
172.20.10.1        36:c0:59:97:84:0   UHLWIir        27       96     en0    768
172.20.10.2        127.0.0.1          UHS             0        0     lo0

Internet6:
Destination                             Gateway                         Flags         Netif Expire
default                                 fe80::34c0:59ff:fe97:8400%en0   UGc             en0
::1                                     link#1                          UHL             lo0
2600:1014:b107:3b0::/64                 link#4                          UC              en0
2600:1014:b107:3b0:1610:9fff:fee3:9417  14:10:9f:e3:94:17               UHL             lo0
2600:1014:b107:3b0:34c0:59ff:fe97:8400  36:c0:59:97:84:0                UHLWIi          en0
2600:1014:b107:3b0:d8a9:c2ee:6fb0:3609  14:10:9f:e3:94:17               UHL             lo0
fd00:6587:52d7::/48                     fd00:6587:52d7:1514:812b:90b3:603e:b815 UGCS          utun0
fd00:6587:52d7:1514::/64                fe80::812b:90b3:603e:b815%utun0 Uc            utun0
fd00:6587:52d7:1514:812b:90b3:603e:b815 link#6                          UHL             lo0
fdd7:9360:1c6c:b8ef::/64                fe80::812b:90b3:603e:b815%utun1 Uc            utun1
fdd7:9360:1c6c:b8ef:812b:90b3:603e:b815 link#7                          UHL             lo0
fe80::%lo0/64                           fe80::1%lo0                     UcI             lo0
fe80::1%lo0                             link#1                          UHLI            lo0
fe80::%en0/64                           link#4                          UCI             en0
fe80::223:12ff:fe55:4329%en0            0:23:12:55:43:29                UHLWIi          en0
fe80::1610:9fff:fee3:9417%en0           14:10:9f:e3:94:17               UHLI            lo0
fe80::34c0:59ff:fe97:8400%en0           36:c0:59:97:84:0                UHLWIir         en0
fe80::7256:81ff:fe88:c16d%en0           70:56:81:88:c1:6d               UHLWIi          en0
fe80::daa2:5eff:fe8b:d950%en0           d8:a2:5e:8b:d9:50               UHLWIi          en0
fe80::e6ce:8fff:fe34:b772%en0           e4:ce:8f:34:b7:72               UHLWIi          en0
fe80::%utun0/64                         fe80::812b:90b3:603e:b815%utun0 UcI           utun0
fe80::812b:90b3:603e:b815%utun0         link#6                          UHLI            lo0
fe80::%utun1/64                         fe80::812b:90b3:603e:b815%utun1 UcI           utun1
fe80::812b:90b3:603e:b815%utun1         link#7                          UHLI            lo0
ff01::%lo0/32                           fe80::1%lo0                     UmCI            lo0
ff01::%en0/32                           link#4                          UmCI            en0
ff01::%utun0/32                         fe80::812b:90b3:603e:b815%utun0 UmCI          utun0
ff01::%utun1/32                         fe80::812b:90b3:603e:b815%utun1 UmCI          utun1
ff02::%lo0/32                           fe80::1%lo0                     UmCI            lo0
ff02::%en0/32                           link#4                          UmCI            en0
ff02::%utun0/32                         fe80::812b:90b3:603e:b815%utun0 UmCI          utun0
ff02::%utun1/32                         fe80::812b:90b3:603e:b815%utun1 UmCI          utun1

Notice that none of the entries in there contains any mention of source. They are all Destination, Next Hop, Flags, and (outbound) Interface.

RAs can contain multiple prefixes. They do not contain default routes. The contain a flag that indicates that the router sending the RA is a candidate default router.

> I believe IPv6 was wrongly designed from the get-go in this aspect. Routing information and prefix annuncement should be coupled together, not separately. So src, dst and routing should belong together instead of being treated as separate the way it's done right now with routing, RA prefix announcement and address selection being completely separate entities.

They really shouldn't. Source-based routing is a hack. It's also known as "Policy based routing". Users that require such features can configure them on routers that support them. However, they are not part of the default way that routing is handled, nor should they be.

> I also believe RIOs should be scoped, so basically a RIO should also have a source prefix in it's announcement. Src, dst, route. Together. This way a RIO could indicate that ULA should communicate with ULA and nothing else. If you don't have a ULA address, you can't send packet to ULA destinations.

There's actually no valid reason to place that limitation on ULA. It is perfectly valid within the scope of a set of ULA addresses to reach them from GUA addresses within that routing scope and vice versa. What is not valid is to expect that ULA addresses are valid for reaching the entire internet.

Baking in the kind of policy-based routing you describe not only into every host, but into all of the RAs and RIOs would seriously complicate what was intended to be a simple, lightweight protocol which serves its purpose very well.

ULAs and policy based routing are edge corner cases. We should not look at complicating and breaking the more general, more widely used, and more common mechanisms in order to chase after solutions for these corner cases.

Owen

---

From: Mark Smith <[email-masked]>
Date: Fri, 22 Mar 2013 16:42:24 -0700 (PDT)

----- Original Message -----
> To: Brian E Carpenter <[email-masked]>
> Sent: Saturday, 23 March 2013 5:30 AM
> Subject: Re: [v6ops] questions regarding rfc6204bis (draft-liu-v6ops-ula-usage-analysis)
> 
> 
>>>>>>  RA is not forbidden. Default route via RA is forbidden. RIO 
> via
>>>>>>  RA is perfectly fine.
>>>>> 

I'd go even more abstract and say that all a default route represents is a pointer to a next hop device that *might* have better knowledge of how to get to the destination than the current device, with it's default route. This is why the behaviour of a device with multiple default routes is either unpredictable or implementation specific, because there is no way to tell from default routing information which of the next hop devices may have better routing information for a particular destination.

Commonly the default route points towards the Internet, but only because it is assumed that the destination is likely to exist on the Internet. The DFZ generally will have that knowledge, but that can be inaccurate too.

One of the best terms I've heard for routing information is that it is a 'hint' that destination exists, not an assurance. The destination might exist at the time the first router with knowledge of the route for a destination forwards the packet, but as the packet is in flight along the path, the destination may become unavailable (e.g., host crashes, the last hop router crashes, or a link fails). There is latency in the routing system, so the routing system may claim, or rather, provide a hint, that the destination currently exists, when in fact it doesn't at a particular moment. The 'hint' terminology, and other general discussions related to flat verses hierarchical addressing are in the following paper (which also explains why MAC addresses are 48 bits)

48-bit Absolute Internet and Ethernet Host Numbers

http://ethernethistory.typepad.com/papers/HostNumbers.pdf

<snip>

Regards,
Mark.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 23 Mar 2013 02:40:43 +0100 (CET)

On Fri, 22 Mar 2013, Owen DeLong wrote:

> RAs can contain multiple prefixes. They do not contain default routes. 
> The contain a flag that indicates that the router sending the RA is a 
> candidate default router.

I am well aware how this is designed. I am saying I want it changed.

> They really shouldn't. Source-based routing is a hack. It's also known 
> as "Policy based routing". Users that require such features can 
> configure them on routers that support them. However, they are not part 
> of the default way that routing is handled, nor should they be.

I have been known to say "whatever process was used when the answer was 
<policy based routing> is wrong during that process". However, what I'm 
talking about here is gateway selection at the host depending on what IPv6 
address it chose to use for this communication. Think IPv4 and IPv6. There 
is no reason for a router to choose its IPv4 default gateway for IPv6 
communication, nor is there really any reason for the host to choose 
gateway 1 when it's using an IPv6 address created based on RAs seen from 
gateway 2 (other than that's the way it was designed historically).

> There's actually no valid reason to place that limitation on ULA. It is 
> perfectly valid within the scope of a set of ULA addresses to reach them 
> from GUA addresses within that routing scope and vice versa. What is not 
> valid is to expect that ULA addresses are valid for reaching the entire 
> internet.

I believe this is up to the routing policy of the network.

> Baking in the kind of policy-based routing you describe not only into 
> every host, but into all of the RAs and RIOs would seriously complicate 
> what was intended to be a simple, lightweight protocol which serves its 
> purpose very well.

I believe the discussion we've seen here says otherwise.

> ULAs and policy based routing are edge corner cases. We should not look 
> at complicating and breaking the more general, more widely used, and 
> more common mechanisms in order to chase after solutions for these 
> corner cases.

A multihomed routed home is a pipe dream unless we change things.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 23 Mar 2013 08:36:57 +0000

On 22/03/2013 18:30, Owen DeLong wrote:
> Routes are destination based, not source based, 

In a multi-prefix network, that is a bug. (I'm not saying we don't have
to consider today's running code, but we also have to do better in future.)

   Brian

---

From: Owen DeLong <[email-masked]>
Date: Sat, 23 Mar 2013 11:46:34 -0700

On Mar 22, 2013, at 18:40 , Mikael Abrahamsson <[email-masked]> wrote:

> I have been known to say "whatever process was used when the answer was <policy based routing> is wrong during that process". However, what I'm talking about here is gateway selection at the host depending on what IPv6 address it chose to use for this communication. Think IPv4 and IPv6. There is no reason for a router to choose its IPv4 default gateway for IPv6 communication, nor is there really any reason for the host to choose gateway 1 when it's using an IPv6 address created based on RAs seen from gateway 2 (other than that's the way it was designed historically).

Which to my mind is just policy based routing implemented on the source host.

In terms of protocols, IPv4 and IPv6 are already separate routing tables and that will not happen. You cannot forward an IPv4 packet to an IPv6 next-hop or vice versa. That is already the case today.

(Note, tunneling is not an exception to this. Once you encapsulate the IPv6 packet in an IPv4 packet for the tunnel, it is now an iPv4 packet that is actually going to the IPv4 next hop).

> I believe this is up to the routing policy of the network.

Correct. I was responding to a claim that said limitation should be baked in. It should not. Sounds like we agree.

> I believe the discussion we've seen here says otherwise.

I remain unconvinced. In fact, if anything, the discussion here has shown that ULAs were probably a bad idea in general which creates a number of unnecessary corner cases.

> A multihomed routed home is a pipe dream unless we change things.

Correct. But this is not the direction in which we should be changing them. Breaking the rest of the internet to enable a multihomed routed home is not the answer.

Owen

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 23 Mar 2013 19:53:59 +0100

Le 22/03/2013 16:26, Templin, Fred L a écrit :
> Hi Merike,
>
>> -----Original Message----- From: Merike Kaeo
>> [mailto:[email-masked]] Sent: Friday, March 22, 2013 2:43 AM To:
>> joel jaeggli Cc: Templin, Fred L; Brian E Carpenter; Alexandru
>> Petrescu; [email-masked] Subject: Re: [v6ops]
>> draft-liu-v6ops-ula-usage-analysis
>>
>>
>>>>> -----Original Message----- From: [email-masked]
>>>>> [mailto:[email-masked]] On Behalf
>> Of
>>>>> joel jaeggli Sent: Thursday, March 21, 2013 3:12 PM To: Brian
>>>>> E Carpenter; Alexandru Petrescu Cc: [email-masked] Subject:
>>>>> Re: [v6ops] draft-liu-v6ops-ula-usage-analysis
>>>>>
>>>>>> On 21/03/2013 13:55, Alexandru Petrescu wrote: ...
>>>>>>> A PI GUA for 2-3 Enterprises may work connected mostly
>>>>>>> all the time
>> at
>>>>>>> the same 2-3 places.  But I think 1 billion PI GUAs
>>>>>>> moving around
>> the
>>>>>>> Internet at the speed of 1 new connection/minute may not
>>>>>>> work - it involves 'route churning', i.e. too many
>>>>>>> routing protocol messages
>> per
>>>>>> of complaints about the churn produced by Connexion by
>>>>>> Boeing, which
>> was
>>>>> 1. iirc there were complaints that it was a relatively bad
>>>>> idea. there
>> were
>>>>> no complaints as far as I know due to impact of the rate of
>>>>> prefix
>> churn
>>>>> which was way lower (by orders of magnitude) than the worst
>>>>> offendors out there at the time. The prefix advertisement and
>>>>> withdrawal was in fact done by the groundstatations not the
>>>>> aircraft.
>>>>>
>>>>> There were never hundreds of of transcontinental commercial
>>>>> aircraft engaged in  roaming on the service (there were
>>>>> around 200 planes total with the equipment). There are many
>>>>> more aircraft today operating with satellite or terrestrial
>>>>> internet connectivity and without such
>> behavior.
>>>> This all happened before my time at Boeing, but my
>>>> understanding is that someone noticed prefixes being announced
>>>> and withdrawn due to aircraft mobility and brought the
>>>> situation to light.
>> Connexion By Boeing peaked my interest since I worked for them and
>> back in 2005/6 developed their IPv6 strategy plus configured the
>> testbed ground stations to be dual- stacked (I had a /48 from
>> Boeing's /32 PI routed by NTT....that caused quite the debates
>> internal to NTT since at that time ISPs were still debating merits
>> of doing so).    It was fun trying get the ISPs to tell me the
>> real deal... "no, I don't want a tunnel I want a native eBGP
>> connection and please route my /48".  How times change.
>>
>> I can definitively state that at that time with v6 there was going
>> to be NO ULA usage although yes, there was routing churn that was
>> disliked by ISPs but noone was actively saying it was causing
>> *great harm*.  It was just very unsavory - hence the talks at NANOG
>> and APRICOT and RIPE to explain and get more feedback. [and the
>> folks building the routing had talked to some global ISPs before
>> finally deciding on going that route]
>>
>> Of course using v6 routing at that time if we had gone live *could*
>> have shown interesting global routing behavior :)
>>
>> It's unfortunate Connexion By Boeing went under....we were in
>> process of moving to production test with v6 at the time (early
>> 2006).    Although as Fred has stated, the system is still
>> operational but for a very limited set of folks. Stuck in v4
>> AFAIK.
>
> My understanding was that the service was picked up by Panasonic
> eXConnect.

This is good to know.  May I mention some commercial deployments of
Wi-Fi in vehicles.

Currently 'Wi-Fi is already in use aboard 1600 planes that fly over the
United States' according to a recent respectable paper.  GoGo and OnAir
as operators, and Boeing and Airbus as manufacturers.

I have tried recently one Wi-Fi on-board of flight (gogo with a delta
flight in US). It was NAT for the passengers and no IPv6.

I have also tried recently Wi-Fi on board of the IETF shuttle bus in
Orlando, and Wi-Fi on board of the Thalys train for Brussels.  Both were
NAT for passengers, and no IPv6.

For the Thalys train I could notice handover of the train between 3G and
WiFi in railway station, by checking the end-to-end RTT.

When NAT IPv4 is used on-board of these vehicles, there is probably no
routing churn (the onboard addresses are not propagated to the
infrastructure), and probably little need for Mobile IP.

The on-board WiFi networks of vehicles would be candidates for using ULA
addressing when migrating to IPv6.

Alex

>> As far as mobility scenarios - due to the routing churn issues in
>> v4 I was following NEMO and other mobility scenarios to see how
>> they might be utilized with v6.  Not sure where that went as I
>> stopped following it.
>
> Thanks - Fred [email-masked]
>
>> Whether you use ULA or GUA for mobility has no difference.  The
>> issue comes in whether you have an entirely closed system (air
>> traffic control and some other global mobile entities do) or
>> whether you need to communicate to outside world.  The latter gets
>> more interesting with ULAs.
>>
>> - merike
>
>

---

From: Owen DeLong <[email-masked]>
Date: Sat, 23 Mar 2013 12:11:40 -0700

> addressing when migrating to IPv6.

I sincerely hope not. It's such a pain to make my laptop reachable behind
these NATs. I'm really hoping that pain can be eliminated and that valid
MIP can be made available instead. It is a much cleaner solution. It
allows for the route churn to be limited to within the provider's network if
done properly.

Owen

---

From: Ray Hunter <[email-masked]>
Date: Sat, 23 Mar 2013 20:18:36 +0100

inline.

>> I am well aware how this is designed. I am saying I want it changed.

After looking at homenet architecture I am beginning to agree with Mikael.

AFAIK Never before have we expected an end node to have to chose a
next-hop between 2 or more routers managed by competing AS's on a shared
common link .

We certainly would never do that in an enterprise network.

> In terms of protocols, IPv4 and IPv6 are already separate routing tables and that will not happen. You cannot forward an IPv4 packet to an IPv6 next-hop or vice versa. That is already the case toda…

You seem to be assuming ships in the night dual stack en-to-end.

With the roll out of NAT64, NAT444, NAT 464, NAPT, NPTv6 and who knows
what other translation abominations that hide the real underlying
topology, it is almost impossible for an end node to chose the "correct"
next hop from several on anything except hope.

But that's exactly what we seem to be expecting in the homenet architecture.

---

From: Owen DeLong <[email-masked]>
Date: Sat, 23 Mar 2013 12:55:25 -0700

> But that's exactly what we seem to be expecting in the homenet architecture.

Primarily, I expect that IPv4 outside of the LAN is mostly a temporary problem.

I believe that eventually, NAT46 dongles will replace all of the above absurdities.

As such, I'd rather focus on solutions that meet the true needs of an IPv6 environment than continuing to flail on more ways to increase the complexity of a dying protocol.

Owen

---

From: Ted Lemon <[email-masked]>
Date: Sat, 23 Mar 2013 20:15:33 +0000

On Mar 23, 2013, at 3:18 PM, Ray Hunter <[email-masked]> wrote:
> it is almost impossible for an end node to chose the "correct"

It is not almost impossible.   In most cases, it _is_ impossible.   There are exceptions, but in general you have to just try.

This is not, however, a problem.

---

From: Doug Barton <[email-masked]>
Date: Sat, 23 Mar 2013 13:24:08 -0700

> If it says "Use a ULA prefix!", I would certainly object to BCP.

I agree with this dichotomy as well, FWIW.

Doug

---

From: joel jaeggli <[email-masked]>
Date: Sun, 24 Mar 2013 12:34:34 -0700

> infrastructure), and probably little need for Mobile IP.
Connexion by boeing was also natted. the internal addressing was the 
same on every plane...

It is worth noting that mobility-wise, transcontinental aircraft using 
geostationary satellites are not  poster-children for mobility. On the 
timescales on which roaming occurs you can do all sorts of things that 
are familiar to 6renum/homenet people that don't involve moving pi /24s 
or /48s around.
> addressing when migrating to IPv6.
I would think that they would be good candidates for 6296 style nptv6 
and what prefix is used on the inside is kind of not relevant.

My experience with ip speaking devices in aviation systems is that they 
get certifed for operation in a particular configuration which is likely 
consistent across the population of those devices.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 25 Mar 2013 04:31:14 -0700

> infrastructure), and probably little need for Mobile IP.

I very much doubt it, because your connections would be interrupted all the
time. Next time, try keeping an SSH connection open on the train. If it
doesn't get reset, then no IP addresses are changing.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 25 Mar 2013 13:30:59 +0100

Le 25/03/2013 12:31, Lorenzo Colitti a écrit :
> On Sat, Mar 23, 2013 at 11:53 AM, Alexandru Petrescu
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>> When NAT IPv4 is used on-board of these vehicles, there is probably
>> no routing churn (the onboard addresses are not propagated to the
> I very much doubt it, because your connections would be interrupted
> all the time. Next time, try keeping an SSH connection open on the
> train. If it doesn't get reset, then no IP addresses are changing.

Well, somehow equivalent to ssh - I googled 'what is my IP address'
while in the train, while the train was handed over from the WiFi in the
railway station to the 3G outdoors (as noticed in the RTT change of
ping).  The IP address 'of the train' did not change, neither the IP
address of my laptop.

That means to me a form of Mobile IP was used by the train's Gateway, or
other dynamic VPN registration.

Even if Mobile IP were not used, nor VPN re-registration, the IP address
of my laptop would have been stable, because it is a NAT.  It would be
unnatural for these Gateways to re-DHCP allocate the NATed addresses to
Clients when the Gateway was handed over.

Alex

---

From: joel jaeggli <[email-masked]>
Date: Mon, 25 Mar 2013 08:25:12 -0700

> ping).  The IP address 'of the train' did not change, neither the IP
it's cellular handoff. The data is being carrier over a gtp tunnel to 
the GGSN, why would one expect the the ip address to change?

---

From: joel jaeggli <[email-masked]>
Date: Mon, 25 Mar 2013 08:52:22 -0700

> to consider today's running code, but we also have to do better in future.)
policy based routing exists and works today... one observation I'd make 
though is when your fowarding path is influenced by the source address, 
path changes tend to cause you to forward into a hole, sometimes that's 
intentional, rfc 5635 style. mostly it's that's just a consequnce of for 
example one upstream being down and you having no other choice due to 
your policy.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 25 Mar 2013 16:53:12 +0100

Le 25/03/2013 16:25, joel jaeggli a écrit :
>>> <[email-masked]
>>> <mailto:[email-masked]>> wrote:
>>>
>>>> When NAT IPv4 is used on-board of these vehicles, there is
>>>> probably no routing churn (the onboard addresses are not
>>>> propagated to the infrastructure), and probably little need
>>>> for Mobile IP.
>>>>
>>>
>>> I very much doubt it, because your connections would be
>>> interrupted all the time. Next time, try keeping an SSH
>>> connection open on the train. If it doesn't get reset, then no
>>> IP addresses are changing.
>>
>> while in the train, while the train was handed over from the WiFi
>> in the railway station to the 3G outdoors (as noticed in the RTT
>> change of ping).  The IP address 'of the train' did not change,
>> neither the IP address of my laptop.
>
> it's cellular handoff. The data is being carrier over a gtp tunnel
> to the GGSN, why would one expect the the ip address to change?
>

YEs, typically gtp tunnels stay up and  cellular handovers are often
just link layer change from one BS to another - no change in IP address.

But in this particular case the train 'roams' from one country to
another?  (it's from Belgium to France in this case).  This typically
involves re-connection and change in IP address.

In addition, it may be that this train does handovers
WiFi-UMTS-Satellite, because explanation below.  If so, then obviously a
change in IP address is there (one couldn't keep same IP address across
different access network technologies); yet the change is hidden from
the passenger googling "what is my IP address" - a form of Mobile IP or
VPN re-registration is suppposedly there.

Alex

----------------------------------------------------------------------
In the particular case of the Thalys train, the situation may be as
follows.  The WiFi in-train provider claims that when the train is in
the railway station the train connects to the WiFi in the railway
station.  (additionally, their web page claims actually "UMTS",
"Satellite" and "WiFi" as means to access the Internet.)

When trying it out as simple passenger, one notices a significant
difference in RTT (round trip time) between when the train is in the
railway station (RTT 40ms ping from laptop to google), versus when the
train is quitting the railway station (600ms).  From other experiments,
one knows that 40ms is impossible on cellular links (other than LTE
which was not deployed at the time of testing) - hence the station could
only be WiFi.
(details in a public video on youtube ref available upon request).

This makes one think that the train performs a handover between two
different access networks (maybe WiFi and maybe cellular); but yet keeps
same IP address as shown by "what is my ip address".

Alex

>>
>>
>> That means to me a form of Mobile IP was used by the train's
>> Gateway, or other dynamic VPN registration.
>>
>> Even if Mobile IP were not used, nor VPN re-registration, the IP
>> address of my laptop would have been stable, because it is a NAT.
>> It would be unnatural for these Gateways to re-DHCP allocate the
>> NATed addresses to Clients when the Gateway was handed over.
>>
>> Alex
>>
>>
>>

---

From: Philipp Kern <[email-masked]>
Date: Sat, 30 Mar 2013 18:08:59 +0100

> have multiple devices to test.

Ok, the device does not actually revoke the ULA but keeps it. The remaining bit
is still true: you don't get to pick your ULA, not even the subnet bits. In
case somebody wonders about this a screenshot (in German) is attached. Maybe
they hash the MAC or something, a Google search of the ULA prefix does not turn
up anything. They even revoke the ULA prefix correctly when the flag is unset
in the web interface. So maybe I should give them the benefit of the doubt
that the ULA is somewhat random…

Kind regards
Philipp Kern

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 30 Mar 2013 19:28:43 +0100

Le 30/03/2013 18:08, Philipp Kern a écrit :
>>> The Fritzbox CPE a few years back made a failed attempt at using
>>> ULAs. They did exactly that i.e. no random ID, and attempted to
>>> *swap* the ULA for the GUA when the GUA disappeared due to the
>>> WAN link going down and vice versa.
>> I need to check it again but that's exactly what a DTAG CPE
>> (Speedport) in Germany does. You can turn on ULAs through the web
>> interface and don't even get to pick the bits. My personal guess is
>> that DTAG fixed it on all but I don't have multiple devices to
>> test.
>
> Ok, the device does not actually revoke the ULA but keeps it. The
> remaining bit is still true: you don't get to pick your ULA, not even
> the subnet bits. In case somebody wonders about this a screenshot (in
> German) is attached.

(yes, the screenshot shows a web interface of Speedport W 723V, with
logo pink T-mobile.  Among various Netzwerk parameters one can see:

IPv6 ULA local verwenden (use): [unchecked]
Lokale IPv6-Adresse (ULA): fd46:8713:d5b8:0001::1')

By the suggested example algorithm in RFC4193, the overall length of the 
'random' part should be 48, which seems to be the case with the example 
above.)

> Maybe they hash the MAC or something, a Google search of the ULA
> prefix does not turn up anything. They even revoke the ULA prefix
> correctly when the flag is unset in the web interface. So maybe I
> should give them the benefit of the doubt that the ULA is somewhat
> random…

Simply curious: when you say revoke, is it that it disappears from the 
web interface?  Or that DHCPv6 revoke message is sent?

Thanks for the example use.

Alex

>
> Kind regards Philipp Kern
>
>
>

---

From: Owen DeLong <[email-masked]>
Date: Sat, 30 Mar 2013 12:13:52 -0700

> is still true: you don't get to pick your ULA, not even the subnet bits. In

The screen shot looks like  you DO get to pick the subnet bits in that there's
a greyed out fill-in field. I suspect that when you click the ULA checkbox, that
field gets un-greyed and you can put any 16 bit value you want into the
subnet field.

Am I misreading the screen shot?

Owen

---

From: Philipp Kern <[email-masked]>
Date: Sat, 30 Mar 2013 21:05:00 +0100

Owen,

> Am I misreading the screen shot?

sadly so. They both don't activate if you hit any checkboxes (i.e. they are
still greyed out). Just as the "Firewall" "option" is always ticked on (and it
doesn't seem to have any actual option behind it), causing all incoming IPv6
traffic to be dropped.

Kind regards
Philipp Kern

---

From: Philipp Kern <[email-masked]>
Date: Sat, 30 Mar 2013 21:48:27 +0100

On Sat, Mar 30, 2013 at 07:28:43PM +0100, Alexandru Petrescu wrote:
> Simply curious: when you say revoke, is it that it disappears from
> the web interface?  Or that DHCPv6 revoke message is sent?

When the box is unchecked and the settings saved, it will send an RA with
preferred=0s to deprecate the old addresses. No DHCPv6 at all, just plain
RAs.

Kind regards
Philipp Kern

---

From: Owen DeLong <[email-masked]>
Date: Sun, 31 Mar 2013 00:58:33 -0700

> doesn't seem to have any actual option behind it), causing all incoming IPv6

That might be a "customized" artifact of the DT custom firmware load.

Owen