Subject: Testing ULAness

From: Brian E Carpenter <[email-masked]>
Date: Sun, 5 Jun 2016 16:37:12 +1200

Hi,

The IANA IPv6 Special-Purpose Address Registry* has a column marked "Global".
For fc00::/7 (ULA) this is set to "False".

That is surely wrong. ULAs are explicitly defined as having global scope.

This has consequences. For example, in the Python ipaddress module,
the property .is_global returns False on a ULA. The test for ULAness
turns out to be (x.is_private and not x.is_link_local).

*http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml

Regards
   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 5 Jun 2016 13:42:45 +0900

On 5 Jun 2016 1:37 pm, "Brian E Carpenter" <[email-masked]>
wrote:
> That is surely wrong.

Is it?

=====
o Global - A boolean value indicating whether an IP datagram whose
destination address is drawn from the allocated special-purpose address
block is forwardable beyond a specified administrative domain.
=====

Doesn't seem that obvious to me that ULAs are forwardable on the internet.

---

From: Roger Jørgensen <[email-masked]>
Date: Sun, 5 Jun 2016 07:06:28 +0200

> Doesn't seem that obvious to me that ULAs are forwardable on the internet.

Global got nothing todo with being forwardable or not. It is more about if the
prefix is unique or not. This remind me of a discussion with some years ago...

ULA-C, ULA-G etc, one result of all that was
https://www.sixxs.net/tools/grh/ula/

And about Brian's question, ULA-G/ULA-C was an attempt to make them
more true global than ULA, so not sure if the global set to false is wrong.

-- 

Roger Jorgensen           | ROJO9-RIPE
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 5 Jun 2016 17:34:23 +1200

>>> For fc00::/7 (ULA) this is set to "False".

https://tools.ietf.org/html/rfc4193#section-3.3

>> Doesn't seem that obvious to me that ULAs are forwardable on the internet.

Doesn't seem to me that this is the agreed definition of global scope for IPv6.

> more true global than ULA, so not sure if the global set to false is wrong.

ULA/C is a red herring, I think. We explicitly abolished site-local scope,
so if it isn't link-local, the scope is global. That's a matter of definition.

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 5 Jun 2016 14:44:13 +0900

> Doesn't seem to me that this is the agreed definition of global scope for
IPv6.

But it *is* the definition of global used by the registry. I think if you
want the registry to say that ULA is global, the definition needs to change
first.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 6 Jun 2016 07:50:27 +1200

> want the registry to say that ULA is global, the definition needs to change

I agree. And of course the appropriate definition may be different for IPv4.

Maybe I should bring this up in Intarea.

   Brian

---

From: [email-masked]
Date: Sun, 5 Jun 2016 21:57:50 +0200

Brian,

> Maybe I should bring this up in Intarea.

RFC4773:
7.  The registry will also note, for each designation, the intended
       routing scope of the address, indicating whether the address is
       intended to be routable only in scoped, local, or private
       contexts, or whether the address prefix is intended to be routed
       globally.

http://tools.ietf.org/html/rfc4193#section-4.1

ULA addresses does not have global routing scope so the registry is correct.
I would be clearer if s/global/global routing scope/ in the IANA registry.

Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 6 Jun 2016 08:50:32 +1200

>        contexts, or whether the address prefix is intended to be routed

Note that RFC4773 was obsoleted by RFC6890, so that's already a bug in the registry.
This paragraph has been blown away. RFC6890 defines 'Global' in the same words used
in the registry, and I believe those words are inconsistent with the IPv6 RFCs.

> I would be clearer if s/global/global routing scope/ in the IANA registry.

Firstly, this is a very unfortunate situation. We are using the same word
to mean two significantly different things. If you think of the decisions you
might need to make about an address, having (not global) different from (local)
is an odd thing. By introducing the notion of 'private' which is not part
of the IPv6 notion of scope, RFC4773 added confusion, IMNSHO. That has been
removed by RFC6890, but is still present in (for example) Python.

What's the real meaning of 'global' in IPv6? All I can see is 'forwardable
beyond this subnet'. Beyond that, any GUA or ULA can be dropped by any router
that feels like it; we simply have a recommendation that ULAs should be dropped
at some administrative boundary.

   Brian

P.S. I am not raising this to be picky. I'm raising it because I had to code
around it a couple of days ago, when my ISP failed to give me an IPv6
prefix and my FritzBox gave me a ULA instead. It broke my code because the
ULA tested as (not global).

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Sun, 5 Jun 2016 22:51:42 +0000

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E Carpenter

> P.S. I am not raising this to be picky. I'm raising it because I had
> to code around it a couple of days ago, when my ISP failed to give me
> an IPv6 prefix and my FritzBox gave me a ULA instead. It broke my code
> because the ULA tested as (not global).

Yes, and the FritzBox was right in doing so. ULAs should not be routable globally, even if there's a reasonably good chance that the prefix might be unique. (There's no uniqueness test of any kind, however.)

As a philosophical point, it seems that whenever we try too hard to make rules for IPv6 so different from the rules that evolved in IPv4, we run into trouble. This looks like another example. ULAs might not be RFC 1918 private addresses de jure, but I think it's not so far-fetched to think of them that way de facto. ULAs should be routable as much as RFC 1918 addresses are routable. Route all you like, within your administrative domain. Isn't this the way they're meant to be used?

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 6 Jun 2016 11:17:28 +1200

> Yes, and the FritzBox was right in doing so. ULAs should not be routable globally, even if there's a reasonably good chance that the prefix might be unique. (There's no uniqueness test of any kind,…

Of course. I was pleased with my FritzBox, it did exactly the right thing.

> As a philosophical point, it seems that whenever we try too hard to make rules for IPv6 so different from the rules that evolved in IPv4, we run into trouble. This looks like another example. ULAs…

Exactly. But this isn't correctly reflected by a Boolean notion of global scope.
(Neither is 100.64.0.0/10 .)

    Brian

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Mon, 06 Jun 2016 10:01:20 -0400

I agree with Lorenzo.
ULAs when created properly are probably globally unique, but there is
no guarantee.  They are RFC1918-like.

That's why you don't get reverse DNS or whois.
It's why I'd really like to revisit ULA-C, but I'm mostly alone in this view.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 06 Jun 2016 16:10:28 +0200

I will be happy to work on that as well …

I tried a couple of times, the main issue is that we also need to define the “central” registration authority. One option will be IANA. The other one the RIRs (they could delegate to one, or to the NRO, or a central registry handled by all them). Probably to be able to be done by the RIRs, we need to global policy (I tried to push that as well in the 5 regions, no success), and a “registration fee”.

May be the IETF can just ask IANA to hold that registry for free as part of the IETF-IANA services agreement.

Saludos,
Jordi

-----Mensaje original-----
De: ipv6 <[email-masked]> en nombre de Michael Richardson <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 6 de junio de 2016, 16:01
Para: IETF IPv6 Mailing List <[email-masked]>
Asunto: Re: Testing ULAness

>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>[email-masked]
>Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------

---

From: Kerry Lynn <[email-masked]>
Date: Mon, 6 Jun 2016 11:28:41 -0400

On Sun, Jun 5, 2016 at 4:50 PM, Brian E Carpenter <
[email-masked]> wrote:

> It appears the idea of making "global" N/A for ULAs was suggested by Errata
ID 3879 but rejected: https://www.rfc-editor.org/errata_search.php?rfc=6890
I haven't found a discussion thread on the topic; perhaps Ted can provide
additional insight.

Kerry

---

From: Roger Jørgensen <[email-masked]>
Date: Mon, 6 Jun 2016 19:41:28 +0200

On Mon, Jun 6, 2016 at 4:01 PM, Michael Richardson
<[email-masked]> wrote:
<snip>
> It's why I'd really like to revisit ULA-C, but I'm mostly alone in this view.

no you're not alone there, I'm in on it to. Sixxs showed us how easy
it could be done. The framework don't have to be that complicated to
describe either but we'll see.

--

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 7 Jun 2016 08:25:44 +1200

Changing to the subject to what you are talking about...

> describe either but we'll see.

It still baffles me why anyone would think this is useful. For any of the
use cases for ULAs, what do I gain by registering the prefix?

    Brian

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 06 Jun 2016 22:31:43 +0200

Making sure is not “just” probabilistically unique?

The question may be should be “are there use cases for ULA?”. If there are use cases (for example) which really make sense to use ULA inside organizations and those organizations one day are involved in a merge process, ULA-C will make sure there is not a clash.

I don’t recall if there is any good document about those possible use cases, may be we need to figure that before agreeing in the need for ULA-C (or even ULA at all ;-) ! ).

Regards,
Jordi

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 7 Jun 2016 08:35:38 +1200

> I haven't found a discussion thread on the topic; perhaps Ted can provide

The problem is deeper, I think: we are using "global" to mean two different
things. There probably isn't a binary fix to that problem. It was correct
to reject the erratum for the meaning of 'global' used in RFC6890, but
that is different from the meaning in RFC4193.

I wouldn't care if it didn't have practical implications.

    Brian

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 6 Jun 2016 20:37:53 +0000

Hi Brian,

> Maybe I should bring this up in Intarea.

Yes. That would be a good venue for this discussion (as are 6man and v6ops). 
I am also a bit uncomfortable with this inconsistency between the registry 
and the protocol. It would be worthwhile getting this resolved.

Thanks
Suresh

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 7 Jun 2016 08:41:33 +1200

> Making sure is not “just” probabilistically unique?

Right. I don't see the point. In the case that two networks merge, checking for clashing
prefixes would be a tiny part of the overall problem.

> The question may be should be “are there use cases for ULA?”. 

draft-ietf-v6ops-ula-usage-considerations

We're strongly recommending ULAs in Anima, for example.

   Brian

> If there are use cases (for example) which really make sense to use ULA inside organizations and those organizations one day are
involved in a merge process, ULA-C will make sure there is not a clash.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 6 Jun 2016 21:26:34 +0000

From: ipv6 [mailto:[email-masked]] On Behalf Of JORDI PALET MARTINEZ

> The question may be should be “are there use cases for ULA?”. If there
> are use cases (for example) which really make sense to use ULA inside
> organizations and those organizations one day are involved in a merge
> process, ULA-C will make sure there is not a clash.

Yes, there are use cases for ULAs, IMO. And my idea on intra-organizational uniqueness would be, by all means, let each organization take care of that aspect on their own.

The nice thing about ULAs, and equally about IPv4 private address blocks, is that an organization can architect their network to best suit their specific needs, without involving any IP address registry, when the services of a registry are not necessary. If we allow ULA prefixes to be registered, we'd be creating a requirement to check whether my ULA prefix scheme conflicts with someone else's internal network ULA prefix scheme. Which is just about the same as using global addresses.

Bert

---

From: Erik Kline <[email-masked]>
Date: Tue, 7 Jun 2016 06:42:56 +0900

> and the protocol. It would be worthwhile getting this resolved.

In some ways this seems like he ongoing difference between
"addressing" and "routing".  A "global scope address" is not the same
as a "globally routable address".

Still, I agree it would be best to be maximally precise wherever the
word "global" is used.

---

From: David Farmer <[email-masked]>
Date: Mon, 6 Jun 2016 16:51:51 -0500

> use cases for ULAs, what do I gain by registering the prefix?

Just having a registered prefix like Sixxs does, I don't find useful
either.  However, registered uniqueness, with functioning reverse-DNS
and default policy of non-routed of ULA-Central could provide, I would
find interesting.

That said, the need for reverse-DNS can be part of a justification for
PI (an end user assignment in ARIN parlance), at least within the ARIN
region.

So, I don't see a desperate need for ULA-C, but I'm certainly not
opposed to ULA-C and would support work on it.  I'll note when dealing
with people with security hats on, the default non-routed policy of
ULA-C (or ULA-Random for that matter) has it's advantages over PI.  It
seems to give them an extra-warm fuzzy, that if we leak packets people
at the other end, or along the way, "might" discard them. :)

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: David Farmer <[email-masked]>
Date: Mon, 6 Jun 2016 17:05:58 -0500

> Doesn't seem that obvious to me that ULAs are forwardable on the internet.

But there is nothing explicitly prohibiting them being forwarded
(routed) out of an administrative domain either.  That might be the
default expectation most people have, but that's all it is a default
expectation, it's not an actual requirement.  So, I can argue both
sides of this one.  Which tells me which ever way it ends up there
should be a footnote pointing to more details.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 7 Jun 2016 09:51:16 +0900

On Tue, Jun 7, 2016 at 7:05 AM, David Farmer <[email-masked]> wrote:

> (routed) out of an administrative domain either.

RFC 4193 says that they should not be forwarded out of a site:

   Site border routers and firewalls should be configured to not forward
   any packets with Local IPv6 source or destination addresses outside
   of the site, unless they have been explicitly configured with routing
   information about specific /48 or longer Local IPv6 prefixes.
...
   Routers that maintain peering arrangements between Autonomous Systems
   throughout the Internet should obey the recommendations for site
   border routers, unless configured otherwise.

and this text in RFC 7084 says that home routers MUST NOT forward ULAs out,
either:

   ULA-4:  By default, the IPv6 CE router MUST act as a site border
           router according to Section 4.3 of [RFC4193] and filter
           packets with local IPv6 source or destination addresses
           accordingly.

I think the registry is correct in saying that these addresses are not
global according to its definition of global.

---

From: David Farmer <[email-masked]>
Date: Mon, 6 Jun 2016 21:22:02 -0500

Sent from my iPhone
> On Jun 6, 2016, at 19:51, Lorenzo Colitti <[email-masked]> wrote:
> 
> and this text in RFC 7084 says that home routers MUST NOT forward ULAs out, either:
> 
> I think the registry is correct in saying that these addresses are not global according to its definition of global.

... unless explicitly configured ...

To me that means; not prohibited, just not allowed by default, does it mean something else to you? 

Even with the definition of "global" use by the registry, a footnote would have seemed appropriate to me, because a strait "false" seems misleading or at least a serious oversimplification.  That said, a strait "true" would have been even more wrong with that definition. 

David Farmer

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 7 Jun 2016 15:55:07 +1200

> Even with the definition of "global" use by the registry, a footnote would have seemed appropriate to me, because a strait "false" seems misleading or at least a serious oversimplification.  That s…

All true. However, the addressing architecture says this (quoting 4291bis):

   The type of an IPv6 address is identified by the high-order bits of
   the address, as follows:

      Address type         Binary prefix        IPv6 notation   Section
      ------------         -------------        -------------   -------
      Unspecified          00...0  (128 bits)   ::/128          2.5.2
      Loopback             00...1  (128 bits)   ::1/128         2.5.3
      Multicast            11111111             ff00::/8        2.7
      Link-Local unicast   1111111010           fe80::/10       2.5.6
      Global Unicast       (everything else)
...
   Future specifications may redefine one or more sub-ranges of the
   Global Unicast space for other purposes, but unless and until that
   happens, implementations must treat all addresses that do not start
   with any of the above-listed prefixes as Global Unicast addresses.

(and the ULA spec is consistent with that).

So, there are two properties that are getting confused here:

  "1. Global scope (and routeable off-link)" - what the addressing architecture says.

  "2. Globally routed (if you're lucky)" - what the IANA text and RFC6890 say.

ULAs match #1 but not #2.

Just saying "Global" does not distinguish #1 from #2.

I find this unsatisfactory. I wish we'd picked it up when reviewing RFC6890.

    Brian

---

From: Jen Linkova <[email-masked]>
Date: Tue, 7 Jun 2016 10:17:38 +0200

> that is different from the meaning in RFC4193.

You are right. We say 'global' but mean either 'global scope' or
'globally routable'.
The former is related to semantic: ULA is meaningful globally.
The latter is more about policy: those addresses are not supposed to
be seen outside of an administrative domain (and the borders of such
domain are quite flexible).
This thread itself is quite good illustration of the confusion...

> I wouldn't care if it didn't have practical implications.

I think it would be nice to get it fixed. Not sure if updating rfc6890
would solve the issue however...

-- 
SY, Jen Linkova aka Furry

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 7 Jun 2016 19:09:46 +0900

> The former is related to semantic: ULA is meaningful globally.

Realistically, I don't think it's feasible to have global meaning without
global reachability. People just configure fd00::/64 all over the place,
grab /16 blocks out of fd00::/8 without regard for collisions, etc.

---

From: Jen Linkova <[email-masked]>
Date: Tue, 7 Jun 2016 13:17:14 +0200

On Tue, Jun 7, 2016 at 12:09 PM, Lorenzo Colitti <[email-masked]> wrote:
> global reachability.

Imagine  I bought an island somewhere near Australia, called it
Brittia and founded a micronation there, Rainbow Kingdom with a city
called Asgard being its capital.
Now I'm sending you a birthday postcard with sender's address:
"Southern Hemisphere,  Brittia, Rainbow Kingdom, Asgard, Aardvark
lane, bld.5".
That address has a global meaning (let's assume I've been following
RFCs..ensured that name is unique) but you probably would not be able
to reply (until Japan recognizes my Rainbow Kingdom) .

So if I build a network and use fd38:5e40:c5d8::/48 prefix (all my
ISPs told me that they do not support IPv6 as nobody is asking for
it...) - that prefix is most likely unique across Internet, has global
meaning (global scope by definition) and I can use it to talk to my
friend's network (fd43:d49:72a1::/48) over the GRE tunnel we built.
But it is not globally reachable.
Or I can get an address space from RIPE but use for some internal
isolated network and never ever advertize it. It would have global
meaning but no reachability whatsoever.

>People just configure fd00::/64 all over the place,

To be honest I'd rather avoid mixing discussions about standards and
semantics and discussions about stupid things people do. I've seen
people grabbing random /22 from RIPE address space and advertising it
in other region saying 'or, I checked our RIR, does not look like they
have it assigned to anyone so I assume it is free and I can use it...'
;) Or shall I mention  1.1.1.0/24 stories? :)

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Tue, 7 Jun 2016 13:57:13 +0200

Hi Jordi and all,

> Making sure is not “just” probabilistically unique?

Yep.

> The question may be should be “are there use cases for ULA?”. If
> there are use cases (for example) which really make sense to use ULA
> inside organizations and those organizations one day are involved in
> a merge process, ULA-C will make sure there is not a clash.

There was a discussion in 2011 about ULA-Cs here:
https://mailarchive.ietf.org/arch/msg/ipv6/Wm8un5ax2nq1SHCURMJGNJbPeUs
and use cases where on-board networks of automotives (cars, planes, etc.).

One suggestion was, however, to use ordinary global addresses from RIRs
instead of ULA-Cs.
I'm not sure what happens if the company goes bankrupt and the
registration is void - presumably there are enough addresses so that
those prefixes will never be reassigned. However, vehicles need to have a
rigorous filter for their on-board network anyway and need to cope with
colliding prefixes at the outside.

Regards,
 Roland

---

From: Kerry Lynn <[email-masked]>
Date: Tue, 7 Jun 2016 10:45:25 -0400

On Mon, Jun 6, 2016 at 11:55 PM, Brian E Carpenter <
[email-masked]> wrote:

> > Even with the definition of "global" use by the registry, a footnote
> would have seemed appropriate to me, because a strait "false" seems
> misleading or at least a serious oversimplification.  That said, a strait
> "true" would have been even more wrong with that definition.
>
> This is precisely what Errata ID 3879 proposed: that ULAs did not conform
to
the RFC6890 definition of "Global" and therefore this field in the IANA IPv6
Special-Purpose Registry should have the value "N/A" along with a pointer to
RFC4193.  My larger point is that this has been litigated previously and it
might
be helpful to have that context (but I haven't found it).

> Surely this is reflected by the RFC6890 definition of "Forwardable"?

  "2. Globally routed (if you're lucky)" - what the IANA text and RFC6890
> say.
>
> It seems RFC6890 is using "Global" in this context, to mean "Forwardable
across a public network".

> Right, which is probably why RFC6890 and the special-purpose registries
use two bits (actually three if you include "Destination") to specify
behavior.
The current settings for ULAs are the same as for Private-Use ranges in the
IANA IPv4 Special-Purpose Address Registry.

>
> What would be your suggested mitigation?

Kerry

---

From: Michael Richardson <[email-masked]>
Date: Tue, 07 Jun 2016 12:04:09 -0400

> use cases for ULAs, what do I gain by registering the prefix?

1) reverse DNS.
2) whois.
3) and the above gives you trackability when the traffic escapes into a place
   where it is not wanted.

(For those who think split-horizon DNS can handle reverse DNS for non-convex
networks, I suggest that you go back to your 1992-era Sun3,
with the application-layer gateway. Turn off all your VPNs, and never think
about using a computer or smartphone.  And, even in the convex-ness of the
early days, it never even worked then properly then, and I was there, and I
tried hard)

---

From: Philip Homburg <[email-masked]>
Date: Tue, 07 Jun 2016 18:15:03 +0200

>3) and the above gives you trackability when the traffic escapes into a place

Assuming that the difference between ULA-C and PI space is that ULA-C is
not routable, are there really that many parties that want to get
unroutable space? 

It could be that I'm only thinking of the RIPE region where PI space is
50 euro per month. But for that money I'd rather get PI just in case I do
want to announce it at a later time.

---

From: Antonio Prado <[email-masked]>
Date: Tue, 7 Jun 2016 18:21:20 +0200

> 3) and the above gives you trackability when the traffic escapes into a place

when one needs all of those, why use ULA?
so, rather than a special-purpose address block, one should actually get
a global unicast address assignment

--
antonio

---

From: Roger Jørgensen <[email-masked]>
Date: Tue, 7 Jun 2016 20:19:06 +0200

> a global unicast address assignment

There are two different, very different views on this, the purely
technical and the more realistic view.
Why should I go to an RIR and all that when I just need something
unique for whatever I'm building? Actual - what RIR should I contact?
RIPE NCC where I have my HQ, ARIN where I have my chip and internal
system being build or APNIC where it's all put together?

I would rather go to a "reseller"/whatever along the line of how
domain names are done, and use those addresses. It's unique and due to
the nature of the space it will (really should never) show up in the
global routing table, it's unique global but only reachable local
where I want it to be.

ULA also have one other nice property, if I remember (and understand)
RFC6724 section 2.1 policy table correct, given a computer have two
IPv6 addresses, global and one ULA, it will use ULA for internal
communication and global for global, right?

--

---

From: Jen Linkova <[email-masked]>
Date: Tue, 7 Jun 2016 21:51:35 +0200

> communication and global for global, right?

Yes, and it could be quite handy in some scenarios, such as keeping
your network working internally even if your ISP uplink is down. If
you use ULA together with GUA (assigned by your ISP(s)), ULAs can be
used for intranet communication.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 07 Jun 2016 22:24:44 +0200

>global routing table, it's unique global but only reachable local

In the RIPE region you would go to a reseller. It is called 'sponsoring LIR'
but there is no practical difference. 

>communication and global for global, right?

Yes, two global prefixes with one of which not announced, would cause a lot
of confusion.

---

From: Bob Hinden <[email-masked]>
Date: Tue, 7 Jun 2016 16:00:58 -0700

I think it would be worthwhile to file an errata on RFC6890 that clarifies this issue.  Then the IANA registry can be updated.  The text in RFC3890 that defines Global is far from clear to me:

 o    Global - A boolean value indicating whether an IP datagram whose
      destination address is drawn from the allocated special-purpose
      address block is forwardable beyond a specified administrative
      domain.

For example, I don’t read that as meaning it has to be in the global routing table, just that two administrative domains would need to accept it.

I also note that RFC4193 that defines ULAs has a section on operational guidelines that would be helpful in this discussion.  That is, please read the RFC before responding to the email thread :-)

Thanks,
Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 8 Jun 2016 13:10:25 +1200

I'm writing a quick draft and I think I'll ask for an agenda slot to
talk this through in Berlin.

   Brian

---

From: Antonio Prado <[email-masked]>
Date: Wed, 8 Jun 2016 12:17:02 +0200

> technical and the more realistic view.

of course it depends on your use case.
btw, if I had a use case where rDNS, whois, 'trackability' (whatever you
mean by that), I would go for GUA

and I would not use ULA for internal communication, as second addressing
scheme either (according to kiss rule)

but I understand that some scenarios would benefit from ULA deployment
--
antonio

---

From: Michael Richardson <[email-masked]>
Date: Wed, 08 Jun 2016 08:40:53 -0400

> mean by that), I would go for GUA

It's very confusing for users, administrators and applications.
Source address selection rules don't really accomodate two GUAs with
different reachability.  We've had verious proposals to deal with this
(including shim6, which I still lament), and HappyEyeBalls helps, but we need
better rules in the host stack.

Source address selection rules would seem to be easier to apply when you have
ULA reachability for internal communication.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Wed, 08 Jun 2016 08:41:15 -0400

---

From: Ole Troan <[email-masked]>
Date: Wed, 8 Jun 2016 14:45:12 +0200

Michael,

> ULA reachability for internal communication.

I just don't see how better rules can solve the problem in the general case.
Good rules is good. But we need approaches like HE, and smarter transport / session layers like MPTCP or MOSH, where you could have some probability or preferences to likely succeeding SA/DA pairs, but you'll fall back to throwing spaghetti on the wall pretty quickly.

Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 8 Jun 2016 22:19:19 +0900

> used for intranet communication.

Note that the specs say that by default the global address should be used.
Otherwise you'll have problems like "host x in ULA A tries to connect to
host y at ULA B and fails, even though both x and y have global addresses
that can reach each other".

---

From: Mark Andrews <[email-masked]>
Date: Thu, 09 Jun 2016 10:42:52 +1000

In message <CAKD1Yr2VdR0nW7udfVosdGj4S9je_MWT8OqZVOZRNdGacU=[email-masked]>
> that can reach each other".

Which shouldn't be a problem is host A's applications are written
for multihomed servers as required by RFC 1123.  Host A tries to
reach the B's ULA address, that fails and it tries the GUA address.
The address selection rules select A's GUA address and the connection
works.

And before you complain about "it takes a lot of time" there is
absolutely nothing stopping A from attempting to contact B over the
second address rapidly like one does with HE for IPv6 vs IPv4.

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Jun 2016 14:00:42 +0900

> second address rapidly like one does with HE for IPv6 vs IPv4.

Nothing stops an implementation from doing that, but no implementations do
that.

As an industry, I think we need a better engineering answer than "try every
possible combination all the time", because trying all combinations all the
time is expensive in terms of CPU time, radio usage, and battery life.

HE was a hack to aid in IPv6 deployment. It's time to retire it.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 09 Jun 2016 15:59:21 +1000

In message <[email-masked]>
> Nothing stops an implementation from doing that, but no implementations do

And they don't do it because the primitive examples for how to
contact multihomed servers don't show how to do that.  It really
is just a matter of education and spending a small amount of time
going back at retrofiting smart multihome server connection semantics.

> HE was a hack to aid in IPv6 deployment. It's time to retire it.

When you can create a network without black holes then it is time
to retire it.  To date I've yet to see anyone do that.

Additionally local ULAs, GUA, other ULAs is the best default sort
order and generally results in a single connection attempt unless
there is a broken link.  Where you use matching ULA, GUA and GUA
as the source address unless it is explicity overridden.

Mark

---

From: [email-masked]
Date: Thu, 9 Jun 2016 09:04:08 +0200

> Nothing stops an implementation from doing that, but no implementations do that.
> 
> As an industry, I think we need a better engineering answer than "try every possible combination all the time", because trying all combinations all the time is expensive in terms of CPU time, radio usage, and battery life.
> 

I disagree.
I a host should optimally try all combinations, monitor them, failover between them, load-share across them...
it can obviously be smart about it, and probabilistically prefer some SA/DA pairs over others at connection time.

I've not seen any other credible alternative to deal with host based multi-homing.
even if you were only connected via a single interface to a multi-prefix network, the network has very limited knowledge about the path performance to the destination.

cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Jun 2016 16:10:16 +0900

> to retire it.  To date I've yet to see anyone do that.

All IPv4-only networks operate in that mode and have been for decades.
Almost 90% of Internet users still only have IPv4.

An unmanaged system with N-way redundancy usually ends up operating with
N-1 failures.

---

From: Mark Smith <[email-masked]>
Date: Thu, 9 Jun 2016 17:47:38 +1000

> it can obviously be smart about it, and probabilistically prefer some SA/DA pairs over others at connection time.

+1

> even if you were only connected via a single interface to a multi-prefix network, the network has very limited knowledge about the path performance to the destination.

I've viewed HE to be a form of packet loss recovery that is across
protocols and across a set of addresses.

I've also thought the combination of Multipath TCP and HE would be
interesting - HE to help bring up the MPTCP subflows faster, rather
than waiting for the first subflow to be established before bringing
up subsequent ones.

Regards,
Mark.

---

From: Brian Haberman <[email-masked]>
Date: Thu, 9 Jun 2016 10:56:14 -0400

Sorry for the delay in responding, but I have been traveling...

> *http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml

I have not been able to work through this entire thread as of yet, but I
wanted to respond to point above as one of the authors of the RFC that
created the registry.

Global is False given that, while probably unique, these addresses are
not guaranteed globally routable. 4193 says:

   Their limitation is in the routability of the prefixes, which is
   limited to a site and any explicit routing agreements with other
   sites to propagate them...

The authors of 6890 discussed this at length both amongst ourselves and
with the larger community. The consensus was that ULAs are not
guaranteed globally routable.

Regards,
Brian

---

From: Erik Kline <[email-masked]>
Date: Thu, 9 Jun 2016 09:30:44 -0700

> it can obviously be smart about it, and probabilistically prefer some SA/DA pairs over others at connection time.

Underlying this is an assumption that you're not paying any additional
cost for those extra keep-alive packets.  We don't yet have a good
platform-independent way of knowing which links are metered and which
are not.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Jun 2016 11:03:35 +1200

> to retire it.  To date I've yet to see anyone do that.

+1. HE saved my sanity two days ago, for example, when my ISP chose
to give me an IPv6 prefix but to black hole all IPv6 packets for a
while. When that becomes physically impossible, we can retire HE.

   Brian

---

From: Bob Hinden <[email-masked]>
Date: Thu, 9 Jun 2016 16:32:26 -0700

Brian,

> On Jun 9, 2016, at 7:56 AM, Brian Haberman <[email-masked]> wrote:
> 

You are correct about RFC4193, but the confusion is that the text in RFC6890 that defines Global doesn’t mention globally routable.  It says something much more limited:

I read that as covered by "any explicit routing agreements with other sites to propagate”, not globally routable.  Some sort of clarification or errata for this RFC and IANA registry is needed.

Bob

---

From: Philip Homburg <[email-masked]>
Date: Fri, 10 Jun 2016 11:39:22 +0200

>while. When that becomes physically impossible, we can retire HE.

Another use case for HE tunnels: my ISP provides native IPv6 but believes
that only a hand full of customers would need reverse DNS and therefor it
it is not a priority.

So I use a HE tunnel for outgoing traffic.

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 10 Jun 2016 11:46:43 +0200

Le 10/06/2016 à 01:03, Brian E Carpenter a écrit :
>> In message
>> <[email-masked]>
>>
>>
, Lorenzo Colitti writes:
>>>> And before you complain about "it takes a lot of time" there
>>>> is absolutely nothing stopping A from attempting to contact B
>>>> over the second address rapidly like one does with HE for IPv6
>>>> vs IPv4.
>>>>
>>>
>> contact multihomed servers don't show how to do that.  It really is
>> just a matter of education and spending a small amount of time
>>> As an industry, I think we need a better engineering answer than
>>> "try every possible combination all the time", because trying all
>>> combinations all the time is expensive in terms of CPU time,
>>> radio usage, and battery life.
>>>

A colleague plans to use Hurricane Electric tunnelling (HE) soon to make
measurements of IPv6 energy consumption on a smartphone; HE because in
that part of the world there is too little chance to get a native IPv6
connection at this time.  It's a topic that makes laugh when mentioned.

There are many other parts of the world where native IPv6 is not for
soon.  In April I discussed with an Argentinian network responsible and
was told that the IPv6 arrival in the Malvine islands is something never
heard of.  And there there was that same smile on her face as when I ask
IPv6 in other regions.  And my experience teaches me there is usually a
certain lapse of time between never hearing of IPv6 and deployment.

Alex

>> there is a broken link.  Where you use matching ULA, GUA and GUA as
>> the source address unless it is explicity overridden.
>>
>> Mark
>>
>
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: "Bajpai, Vaibhav" <[email-masked]>
Date: Fri, 10 Jun 2016 09:54:21 +0000

All,

I think the thread was initially talking about happy eyeballs (HE), but the
recent replies have digressed it into hurricane electric (HE).

Let’s please expand acronyms when using them.

Thanks!

Best, Vaibhav

> On 10 Jun 2016, at 15:16, Alexandre Petrescu <[email-masked]> wrote:
> 

===================================
Vaibhav Bajpai
www.vaibhavbajpai.com

Room 91, Research I
School of Engineering and Sciences
Jacobs University Bremen, Germany
===================================

---

From: Philip Homburg <[email-masked]>
Date: Fri, 10 Jun 2016 12:07:53 +0200

>I think HE meant Happy Eyeballs in this thread not Hurricane Electric. =
>;-)

The discussion on NANOG was larger than this one. :-) I guess using HE for
happy eyeballs is just too confusing.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 10 Jun 2016 13:58:08 +0200

In your letter dated Thu, 9 Jun 2016 09:04:08 +0200 you wrote:
>> As an industry, I think we need a better engineering answer than "try 
>every possible combination all the time", because trying all 
>combinations all the time is expensive in terms of CPU time, radio 
>usage, and battery life.
>>
>it can obviously be smart about it, and probabilistically prefer some 
>SA/DA pairs over others at connection time.
>
>even if you were only connected via a single interface to a multi-prefix 
>network, the network has very limited knowledge about the path 
>performance to the destination.

I can see two problems with happy eyeballs:
1) Only connection setup gets tested. If that connection has bad performance
   there is no fallback
2) There is no happy eyeballs protocol. It is just a vague description of a
   technique. 

For the first problem, MPTCP would be more suitable than happy eyeballs.

For the second problem, I think there should be a clear base line that
can just be implemented. Not an endless variety of possibilities, but
something that is expected to work well in many cases and does not
overload the network.

Of course implementation can go beyond that. But without something that is
simple to convert into code, it may take forever for embedded devices, etc.
to do something sensible in this area.

---

From: David Schinazi <[email-masked]>
Date: Fri, 10 Jun 2016 11:47:30 -0700

I don't know about all the hosts out there, but I know a great many devices that implement a lot of the techniques discussed above.
When an address fails to connect, they fall through the entire list that DNS returned in quick succession.
This is done independently of address family and ensures that the eyeball quickly ends up with a functional connection.
All happy eyeballs recommends is that you may want to try the first address from the second address family sooner than after all of the addresses from the first address family.
If there are different types of addresses (say an ULA and a global address), RFC 6724 source address selection makes sure to use the correct source.
There's no need to try to connect from every single source address to every destination, simply the best source for each destination.
(If the source is multi homed with different global prefixes you may want to try both of these but that's not very widespread at this time)
Regarding MPTCP, all you need is to treat it like regular happy eyeballs TCP at setup time and send multiple SYNs until one connects and then start opening subflows.
Host downtimes and routing blackholes are as much a fact of life as packet loss, sure the network will operate with N-1 failures but it will operate.
If the operator returns multiple addresses in DNS, they probably want eyeballs to use them, not take one and start crying if it doesn't work.
And yes all of this involves complexity but as long as you keep all of it hidden behind a connect-by-name API, it just works™.

David

> On Jun 10, 2016, at 04:58, Philip Homburg <[email-masked]> wrote:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Jun 2016 08:18:18 +1200

> Let’s please expand acronyms when using them.

That's why I changed the subject to 'happiness' but apparently that wasn't
enough of a clue that I thought we were taking about happy eyeballs. But
either HE would have fixed my problem the other day ;-)

   Brian