Subject: [v6ops] 6204bis and WAN disappearing

From: "Dan Wing" <[email-masked]>
Date: Tue, 21 Feb 2012 15:49:52 -0800

Reading draft-ietf-v6ops-6204bis-05, I couldn't determine what the CE router
should do if, after it acquires an IPv6 prefix from its WAN interface, the
WAN interface later goes down.  Requirement G-4 in the specification
(http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-05#section-4.1)
requires the CE router (immediately?) withdraw the prefix on the LAN
interface, but if this text (from draft-ietf-v6ops-6204bis-05) is true:

   1.  Link-local addresses may be insufficient for allowing IPv6
       applications to communicate with each other in the end-user
       network.  The IPv6 CE router will need to enable this
       communication by providing globally scoped unicast addresses or
       ULAs [RFC4193], whether or not WAN connectivity exists.

then withdrawing the globally scoped unicast addresses will break
communication within the home.  This means if my WAN link goes down, IPv6
streaming between my NAS and my speakers breaks which ruins my dinner party.

Can draft-ietf-v6ops-6204bis be more precise describing what happens when
the WAN link fails (should the globally scoped prefix be withdrawn on the
LAN?  Immediately?  After several days?  What about after a reboot of the
CPE?), and can it be more precise to discuss if the CE router has to provide
a globally scoped unicast address or has to provide ULA, or has to provide
both.  As written, devices in the home that rely on the globally-scoped
address will fail if the WAN link fails, and it should not be necessary for
host and CE router implementers to read the tea leaves of
draft-ietf-v6ops-6204bis that ULA is necessary for successful operation of
home network equipment when the WAN fails.

-d

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 22 Feb 2012 12:59:26 +0900

On Wed, Feb 22, 2012 at 08:49, Dan Wing <[email-masked]> wrote:

> communication within the home.  This means if my WAN link goes down,
> IPv6 streaming between my NAS and my speakers breaks which ruins my dinner
> party.
>

Losing connectivity on the WAN won't immediately break your stream, since
the global addresses will not go away, they'll just be deprecated. (If the
outage persists for more than two hours, then yes, it will stop).

That said, I would argue that if you're relying on globally-scoped IPv6
addresses expecting that they will never go away, you're Doing It Wrong.
It's not just that the WAN link could go down - the ISP could decide to
renumber your prefix, or the lease might expire and never be renewed (e.g.,
if you didn't pay your bill).

---

From: Tore Anderson <[email-masked]>
Date: Wed, 22 Feb 2012 09:25:33 +0100

* Dan Wing

> interface

Dan,

That's not what G-4 (or G-5) says. It says that if the CE router loses
its WAN interface (or default route on a still-enabled WAN interface for
that matter), it needs to withdraw itself as a *default router* for the
nodes connected to the LAN.

It does *not* say anything about the prefixes/addresses advertised to
the LAN - they should not be impacted by the WAN interface going down,
except for the fact that the the DHCPv6-PD lease cannot be renewed,
which means that the lifetimes of the lease and the addresses themselves
will eventually reach zero.

-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com

---

From: Rémi Després <[email-masked]>
Date: Wed, 22 Feb 2012 09:28:50 +0100

Le 2012-02-22 à 00:49, Dan Wing a écrit :

> address will fail if the WAN link fails, and

> it should not be necessary for

+1

If the WAN link fails, its last assigned global prefix can advantageously be used locally until the link comes back:
- If it comes back with the same prefix, great.
- If it doesn't, consequences of a prefix change have indeed to be supported, but for a reason that has no relation to link failure.

Now, if an IPv6 LAN starts operation before having any WAN access, any prefix could work that is never routed to any customer site. 
It could be fd00::/48 (neither a ULA prefix, nor a publicly routable prefix, ref the ULA RFC4193).

RD

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

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 22 Feb 2012 04:58:13 -0500

I agree. Separately, shouldn't G3 also say prefix acquisition ?

  G-3: The IPv6 CE router MUST NOT forward any IPv6 traffic between its LAN interface(s) and its WAN interface until the router has successfully completed the IPv6 address acquisition process.

Cheers,
Rajiv

Sent from my Phone

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 22 Feb 2012 13:54:52 +0000

> its WAN interface (or default route on a still-enabled WAN interface
> for that matter), it needs to withdraw itself as a *default router* for the
> which means that the lifetimes of the lease and the addresses
> themselves will eventually reach zero.
> 
> --
> Tore Anderson

I agree with what Tore says the draft says. That's definitely what I understood it to say.
Barbara

---

From: Timothy Winters <[email-masked]>
Date: Wed, 22 Feb 2012 09:05:40 -0500

Hello,
	The CE Routers that have participated in the IPv6 CE Events have implemented Tore/Barbara have stated.  The CE Routers transmit an RA with a lifetime 0 but don't withdraw prefixes.

Regards,
Tim

---

From: Rémi Després <[email-masked]>
Date: Wed, 22 Feb 2012 16:06:05 +0100

+1

RD

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 22 Feb 2012 07:07:18 -0800

> -----Original Message-----
> From: Timothy Winters [mailto:[email-masked]]
> Sent: Wednesday, February 22, 2012 6:06 AM
> To: STARK, BARBARA H
> Cc: Tore Anderson; Dan Wing; [email-masked]; draft-ietf-v6ops-
> [email-masked]
> Subject: Re: [v6ops] 6204bis and WAN disappearing
> 
> Hello,
> 	The CE Routers that have participated in the IPv6 CE Events have
> implemented Tore/Barbara have stated.  The CE Routers transmit an RA
> with a lifetime 0 but don't withdraw prefixes.

I am glad there is high confidence that the spec is accurate.

My worry, though, is it provides insufficient clarity towards hosts,
specifically that hosts should/shouldn't use ULA for communication
amongst themselves within the local network, and should/shouldn't use
ULA when advertising their presence via their rendezvous protocol
(e.g., mDNS).   A sentence such as "With this functionality, hosts
using ULA will be able to continue normal operation during a lengthy
WAN outage" would be a nice addition.

-d

> >>> Reading draft-ietf-v6ops-6204bis-05, I couldn't determine what the
> CE
> >> router

---

From: "Weil, Jason" <[email-masked]>
Date: Wed, 22 Feb 2012 11:38:11 -0500

Dan,

I believe it is still up for discussion what the CE router should do when
the WAN interface transitions to the Down state and may just be an
implementation decision. Two immediate options come to mind including the
one you suggest.

1. Use ULA, if present for home network communication. This requires a
single ULA across a multi-subnet home network (otherwise Link Local would
be sufficient) which does not exist today.

2. Use the last known GUA for home network communication. This requires
adjusting the Valid lifetime on a Link Down Event on the PIO advertised on
the LAN to a sufficiently large number to allow continued communications
until the CE Router either Rebinds the PD Prefix or learns a new one.

I'm still not sold that ULA is the correct solution in this case. This is
more in the domain of a Homenet discussion, although granted the line is
blurry here.

Jason

>> > I agree with what Tore says the draft says. That's definitely what I

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Ole Trøan <[email-masked]>
Date: Wed, 22 Feb 2012 17:50:10 +0100

Jason,

> implementation decision. Two immediate options come to mind including the

I disagree.
on a WAN interface down event according to RFC6204, nothing happens with prefixes/addresses.

> more in the domain of a Homenet discussion, although granted the line is

you are talking about the case where WAN is down and prefix times out?

the 6204 assumption is that you then have the ULA, that you have had the whole time, i.e. no introduction of a new prefix just because of a WAN down/prefix timeout event.

2 is certainly an option as well.

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Feb 2012 17:02:06 +0000

Various people have made the claim that continuing to use the GUA after its lifetime expires is okay as long as you remain disconnected, but this isn't correct.

The reason it isn't correct is that a GUA, used beyond its valid lifetime, has the potential to be immediately invalidated when the WAN reappears.   When I say potential, it might seem like I mean that it's something that could happen, but is unlikely.   But we as protocol wonks have no way to make that statement, because it depends on circumstances we don't control—it depends on the provider's upstream policy.

So this means that if we arrange to kill the GUA when the WAN comes back, if the GUA is no longer valid, then perfectly valid in-home streams will be interrupted.   We might say "oh, that's no problem, let the streams that are running keep using the GUA."

This is still a problem, though, because a device configured with a GUA whose lifetime has expired will not know that its lifetime has expired, because there is no way to communicate this: in IPv6, an address is valid or it is not.   We do get to play with preferred versus valid, and maybe we could deprecate the address and hope that the node wouldn't try to use it to connect anymore, but there's no mechanism for doing this in the IPv6 protocol suite.

So it's quite likely that when the WAN does reappear, the device will try to use its GUA to communicate with devices off the local wire.   If the GUA is no longer valid, it will fail.

Whereas a ULA has limited scope; if a device is configured with a ULA, and the WAN comes back, then the device can immediately get a valid GUA and start communicating with it.   Because all in-home connections are using the ULA, they are not interrupted.

Of course, in-home connections that started out using the GUA and survived the loss of the WAN connection will die when the valid lifetime of the GUA expires.   This is a good reason to try to arrange for all in-home connections to use ULAs always, even when we have a WAN connection.

I realize I'm just reiterating things that have been said before, but given that we are still hearing the notion of keeping the GUA on WAN loss, I think it's worth walking through the argument again.

---

From: "Weil, Jason" <[email-masked]>
Date: Wed, 22 Feb 2012 12:13:23 -0500

>on a WAN interface down event according to RFC6204, nothing happens with

I should have been more specific. I was referring to what steps the CE
Router takes regarding prefixes it generates for use on the LAN
interface/s. I agree with your disagreement that nothing happens to the
original prefix learned on the WAN other than timer countdowns.
>you are talking about the case where WAN is down and prefix times out?

Correct.

>
>the 6204 assumption is that you then have the ULA, that you have had the
>whole time, i.e. no introduction of a new prefix just because of a WAN
>down/prefix timeout event.
>

---

From: Rémi Després <[email-masked]>
Date: Wed, 22 Feb 2012 18:22:18 +0100

Le 2012-02-22 à 18:02, Ted Lemon a écrit :

> The reason it isn't correct is that a GUA, used beyond its valid lifetime, has the potential to be immediately invalidated when the WAN reappears.

Wouldn't it be possible, if it is invalidated to wait, before opening again routes to the WAN, until the internal lifetime of the old one has expired?
Renumbering after a link outage shouldn't be very frequent, right? 

>  When I say potential, it might seem like I mean that it's something that could happen, but is unlikely.   But we as protocol wonks have no way to make that statement, because it depends on circumstances we don't control—it depends on the provider's upstream policy.
> 

There is AFAIK the implicit assumption that all hosts support two IPv6 addresses on a single interface.
I don't think that OS X, for example, does it today.
Then, If the WAN link breaks, all internal sessions are broken, even if the IPv6 prefix doesn't change when the link comes back.

If this point has already been made and answered, please excuse me, a pointer to the answer will be sufficient.

Thanks,
RD

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Feb 2012 18:50:37 +0000

> Renumbering after a link outage shouldn't be very frequent, right? 

What I'm saying is that we don't have the capacity to say that this is the case.   It is dependent both on the connectivity model and ISP policy.

> Then, If the WAN link breaks, all internal sessions are broken, even if the IPv6 prefix doesn't change when the link comes back.

As far as I know OS X supports multiple IPv6 addresses.   I don't know how well it does at address selection, but the OSX guys are pretty smart, so I assume that they implemented ULA correctly.   Might be worth checking out—I have to admit I haven't tried it.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Feb 2012 18:52:42 +0000

On Feb 22, 2012, at 12:22 PM, Rémi Després <[email-masked]<mailto:[email-masked]>> wrote:
Wouldn't it be possible, if it is invalidated to wait, before opening again routes to the WAN, until the internal lifetime of the old one has expired?

Oh, forgot to reply to this.   The answer is that no, you can't, because that is almost necessarily a long time.   You can change the RA to deprecate the old GUA, but then you pretty much have to cross your fingers and hope that the host takes the new prefix lifetimes before it attempts any outgoing connections.

---

From: "Weil, Jason" <[email-masked]>
Date: Wed, 22 Feb 2012 13:54:13 -0500

Might as well continue the age old discussion for us new to the game and
trying to actually implement this stuff...

On 2/22/12 9:02 AM, "Ted Lemon" <[email-masked]> wrote:

>Various people have made the claim that continuing to use the GUA after
>its lifetime expires is okay as long as you remain disconnected, but this
>isn't correct.
>
>The reason it isn't correct is that a GUA, used beyond its valid
>lifetime, has the potential to be immediately invalidated when the WAN
>reappears.   When I say potential, it might seem like I mean that it's
>something that could happen, but is unlikely.   But we as protocol wonks
>have no way to make that statement, because it depends on circumstances
>we don't control‹it depends on the provider's upstream policy.
>
>So this means that if we arrange to kill the GUA when the WAN comes back,
>if the GUA is no longer valid, then perfectly valid in-home streams will
>be interrupted.   We might say "oh, that's no problem, let the streams
>that are running keep using the GUA."
>
>This is still a problem, though, because a device configured with a GUA
>whose lifetime has expired will not know that its lifetime has expired,
>because there is no way to communicate this: in IPv6, an address is valid
>or it is not.   We do get to play with preferred versus valid, and maybe
>we could deprecate the address and hope that the node wouldn't try to use
>it to connect anymore, but there's no mechanism for doing this in the
>IPv6 protocol suite.
>
>So it's quite likely that when the WAN does reappear, the device will try
>to use its GUA to communicate with devices off the local wire.   If the
>GUA is no longer valid, it will fail.

OK I was following but now you are losing me. As soon as the WAN comes
back up, the CE Router advertises itself as a Default router once again.
If the GUA remains unchanged per a successful Rebind of the IA-PD then
communication proceeds off the wire successfully. If the prefix changes or
is no Longer Valid (see Side Question) communication off the wire breaks.
How is this any different from any renumbering event today which requires
breaking old connections?

I see a valid point in here for using ULA for communication to avoid a
renumbering event breaking in-home sessions, but I fail to see how using a
GUA after its lease lifetime expires prior to link up resulting in any
different action than using a GUA whose lease is still valid but which is
no longer routed due to a renumbering event encountered when the link
comes up assuming no explicit reply to the REBIND with valid timer equal
to 0?

Side Question: Is the expected response to a Requesting Router Rebind
event on link bounce for the Server to respond with NotOnLink status as
per 18.1.8 of RCC3315 CONFIRM process? This is for a Confirm messages but
since Confirm is not supported in RFC3633 it is a bit unclear what the
Requesting Router is expected to do next, but I personally would expect a
new SOLICIT.

>
>Whereas a ULA has limited scope; if a device is configured with a ULA,
>and the WAN comes back, then the device can immediately get a valid GUA
>and start communicating with it.   Because all in-home connections are
>using the ULA, they are not interrupted.

>
>Of course, in-home connections that started out using the GUA and
>survived the loss of the WAN connection will die when the valid lifetime
>of the GUA expires.   This is a good reason to try to arrange for all
>in-home connections to use ULAs always, even when we have a WAN
>connection.
>
>I realize I'm just reiterating things that have been said before, but
>given that we are still hearing the notion of keeping the GUA on WAN
>loss, I think it's worth walking through the argument again.
>

Jason

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 22 Feb 2012 19:00:41 +0000

> reappears.

A GUA has the potential to be immediately invalidated when the WAN re-appears, no matter what its valid lifetime is.

Consider the following real-life scenario:
IPv6 connection is via 6rd.
IPv4 address changes every time the IPv4 connection goes down and then up, no matter what the lease was on the original IPv4 address. This happens a lot in the IPv4 world.
IPv6 is down when IPv4 is down.
IPv6 prefix is based on the IPv4 address, so it will change every time the IPv4 address changes.
So the original IPv6 prefix may no longer be useful for Internet connectivity, even if it has time left on the original "valid" timer.

If sudden GUA address/prefix changes are a problem, then I think it would be best to consider this independent of whether or not GUAs are used beyond their valid lifetimes, when the WAN is down. I don't think that such use makes the problem any worse.

Barbara

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 22 Feb 2012 19:02:40 +0000

> > Renumbering after a link outage shouldn't be very frequent, right?

With 6rd, on dynamically assigned IPv4 connections, we're seeing it a lot.
Barbara

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Feb 2012 19:19:27 +0000

On Feb 22, 2012, at 2:00 PM, "STARK, BARBARA H" <[email-masked]<mailto:[email-masked]>> wrote:
If sudden GUA address/prefix changes are a problem, then I think it would be best to consider this independent of whether or not GUAs are used beyond their valid lifetimes, when the WAN is down. I don't think that such use makes the problem any worse.

This argument isn't valid because you are using as an example a transition technology with performance characteristics outside the intended envelope of the IPv6 protocol, and with it you are justifying an assumption about the behavior of applications that are within the intended envelope of the IPv6 protocol.

So yes, this is a real problem, but no, the fact that it is a problem does not mean that instant deprecation of expired GUAs causes no additional harm.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 Feb 2012 08:41:23 +1300

> WAN outage" would be a nice addition.

There's no doubt that homenets, and SOHOs, need to treat prefix renumbering
as a normal event. This is just one of the scenarios that may cause it.

However, I don't think the CPE spec should deal with this, beyond requiring
ULA support in case that is part of the chosen solution. I'd rather see
it as a homenet issue, with possible overlap with 6renum, although
that is chartered for enterprise networks.

    Brian

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 22 Feb 2012 19:47:04 +0000

The IPv6 hosts (and applications that reside on them) inside the home network won't know the difference. CE-router originated native vs 6rd IPv6 interfaces all look alike from inside the LAN. Therefore, I believe that my assumption that LAN-based apps will behave the same, no matter what the WAN IPv6 mechanism is, is well-justified.

Instant deprecation of GUAs does appear to cause problems. Whether or not the original valid lifetime (as set by the access network) has expired, while the WAN is down. It is the instant deprecation of GUAs that apps had been told would be valid for awhile yet, that causes problems. Preventing CE routers from extending the valid lifetime of expired GUAs when the WAN is down will not make the problem go away.
Barbara

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Feb 2012 20:27:37 +0000

On Feb 22, 2012, at 2:47 PM, "STARK, BARBARA H" <[email-masked]<mailto:[email-masked]>> wrote:
The IPv6 hosts (and applications that reside on them) inside the home network won’t know the difference. CE-router originated native vs 6rd IPv6 interfaces all look alike from inside the LAN. Therefore, I believe that my assumption that LAN-based apps will behave the same, no matter what the WAN IPv6 mechanism is, is well-justified.

That's not what I meant.   What I meant is that the fact that a network provisioned with 6rd behaves in a suboptimal way isn't something we need to consider as significant in the long run.   6rd is a transition technology.   So we should optimize our solution for the long term, and not use the bad behavior of transition technology as a justification for allowing the solution to continue to be broken once the transition technology is no longer in use.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 22 Feb 2012 14:56:52 -0600

Folks, please read RFC 4862 for timing out a prefix on prefix Valid
Lifetime expiry and the 2 hours rule from section 5.5.3.  Further read
section 5.5.4 of the same RFC and this text between squared braces
below.

[A preferred address becomes deprecated when its preferred lifetime
 expires.  A deprecated address SHOULD continue to be used as a source
 address in existing communications, but SHOULD NOT be used to
 initiate new communications if an alternate (non-deprecated) address
 of sufficient scope can easily be used instead.]

Then read this bullet from RFC6204bis.

[L-14:  The IPv6 CE router MUST send an ICMPv6 Destination Unreachable
        message, code 5 (Source address failed ingress/egress policy)
        for packets forwarded to it that use an address from a prefix
        that has been deprecated.]

Lastly, the LAN requirements of RFC6204 were agreed upon when RFC6204
was published and also nailed down when RFC6204bis was split into WAN
and LAN documents but RFC 6204 LAN sections were retained.  Thus the ULA
stays in rfc6204bis but no new LAN requirements qualify for rfc6204bis
without new consensus from the WG.

I do not see any issue with rfc6204bis there we are sending so many
emails on this thread.

Regards,

Hemant
 
-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Wednesday, February 22, 2012 12:02 PM
To: Jason Weil
Cc: Dan Wing (dwing); Timothy Winters; STARK, BARBARA H; [email-masked];
[email-masked]
Subject: Re: [v6ops] 6204bis and WAN disappearing

Various people have made the claim that continuing to use the GUA after
its lifetime expires is okay as long as you remain disconnected, but
this isn't correct.

we don't control-it depends on the provider's upstream policy.

So this means that if we arrange to kill the GUA when the WAN comes
back, if the GUA is no longer valid, then perfectly valid in-home
streams will be interrupted.   We might say "oh, that's no problem, let
the streams that are running keep using the GUA."

This is still a problem, though, because a device configured with a GUA
whose lifetime has expired will not know that its lifetime has expired,
because there is no way to communicate this: in IPv6, an address is
valid or it is not.   We do get to play with preferred versus valid, and
maybe we could deprecate the address and hope that the node wouldn't try
to use it to connect anymore, but there's no mechanism for doing this in
the IPv6 protocol suite.

So it's quite likely that when the WAN does reappear, the device will
try to use its GUA to communicate with devices off the local wire.   If
the GUA is no longer valid, it will fail.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 22 Feb 2012 21:03:13 +0000

Thanks. I understand now. But I disagree. I have no direct knowledge of such things, but my crystal ball leads me to believe that transition technologies like 6rd will be around for many years. Longer than the average lifespan of a CE router.

As Brian suggested, I would like to see homenet tackle the question of LAN renumbering. And I think it is outside the scope of 6204bis to say anything on this topic that it doesn't already say.
Barbara

From: Ted Lemon [mailto:[email-masked]]
Sent: Wednesday, February 22, 2012 3:28 PM
To: STARK, BARBARA H
Cc: Rémi Després; Jason Weil; [email-masked]; [email-masked]
Subject: Re: [v6ops] 6204bis and WAN disappearing

---

From: Ole Trøan <[email-masked]>
Date: Wed, 22 Feb 2012 22:14:39 +0100

> As Brian suggested, I would like to see homenet tackle the question of LAN renumbering. And I think it is outside the scope of 6204bis to say anything on this topic that it doesn’t already say.

right, and regardless of transition technologies you will have two variants of renumbering in the home.
flash/instant or controlled/overlapping.

cheers,
Ole

---

From: "Weil, Jason" <[email-masked]>
Date: Wed, 22 Feb 2012 19:26:42 -0500

Hemant,

I don't believe any substantive changes to 6204bis have been suggested. The only suggestion was the inclusion of the sentence that Dan suggested would be useful.

Here was Dan's suggestion:

A sentence such as "With this functionality, hosts
using ULA will be able to continue normal operation during a lengthy
WAN outage" would be a nice addition.

Thanks,

Jason

From: Hemant Singh <[email-masked]<mailto:[email-masked]>>
Date: Wed, 22 Feb 2012 15:56:52 -0500
To: Ted Lemon <[email-masked]<mailto:[email-masked]>>, jason weil <[email-masked]<mailto:[email-masked]>>
Cc: "Dan Wing (dwing)" <[email-masked]<mailto:[email-masked]>>, Timothy Winters <[email-masked]<mailto:[email-masked]>>, "STARK, BARBARA H" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [v6ops] 6204bis and WAN disappearing

Folks, please read RFC 4862 for timing out a prefix on prefix Valid Lifetime expiry and the 2 hours rule from section 5.5.3.  Further read section 5.5.4 of the same RFC and this text between squared braces below.

Lastly, the LAN requirements of RFC6204 were agreed upon when RFC6204 was published and also nailed down when RFC6204bis was split into WAN and LAN documents but RFC 6204 LAN sections were retained.  Thus the ULA stays in rfc6204bis but no new LAN requirements qualify for rfc6204bis without new consensus from the WG.

I do not see any issue with rfc6204bis there we are sending so many emails on this thread.

Regards,

Hemant

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Wednesday, February 22, 2012 12:02 PM
To: Jason Weil
Cc: Dan Wing (dwing); Timothy Winters; STARK, BARBARA H; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [v6ops] 6204bis and WAN disappearing

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Rémi Després <[email-masked]>
Date: Thu, 23 Feb 2012 09:26:43 +0100

1.
2012-02-22 19:50, Ted Lemon:

> As far as I know OS X supports multiple IPv6 addresses.

AFAIK, not for an ordinary user like me.

>   I don't know how well it does at address selection, but the OSX guys are pretty smart, so I assume that they implemented ULA correctly.  

>  Might be worth checking out

Indeed.

2.
2012-02-22 19:52, Ted Lemon:

> Oh, forgot to reply to this.   The answer is that no, you can't, because that is almost necessarily a long time.

Doesn't the next sentence say the opposite, based on the existing specification?

>   You can change the RA to deprecate the old GUA,

> but then you pretty much have to cross your fingers and hope that the host takes the new prefix lifetimes before it attempts any outgoing connections.

Even if it doesn't, it isn't a serious problem: the host is informed in ICMPv6 that unreachability of the destination is due to ingress or egress filtering (Type 1 code 5 per RFC4443).
What it does next is implementation dependent, but checking its source address makes sense.

Besides, this only happens when ISPs change IPv6 prefix assignments, which is always a problem for external connections.

RD

---

From: Rémi Després <[email-masked]>
Date: Thu, 23 Feb 2012 10:08:02 +0100

> IPv4 address changes every time the IPv4 connection goes down and then up, no matter what the lease was on the original IPv4 address. This happens a lot in the IPv4 world.

But probably not a lot where 6rd is deployed. (Personally, my IPv6 prefix hasn't changed since 2008).
In any case, address instability breaks external connections, be they in IPv6 or IPv4. 

> If sudden GUA address/prefix changes are a problem, then I think it would be best to consider this independent of whether or not GUAs are used beyond their valid lifetimes, when the WAN is down. I…

Please see also my answer to Ted.

RD

---

From: Rémi Després <[email-masked]>
Date: Thu, 23 Feb 2012 10:13:58 +0100

Le 2012-02-22 à 21:27, Ted Lemon a écrit :

> On Feb 22, 2012, at 2:47 PM, "STARK, BARBARA H" <[email-masked]> wrote:
> That's not what I meant.   What I meant is that the fact that a network provisioned with 6rd behaves in a suboptimal way isn't something we need to consider as significant in the long run.

Well, if the 6rd network has stable IPv4 addresses and generalized CPEs that support 6rd, it does work as well as one that would use dual-satck routing.

>   6rd is a transition technology.   So we should optimize our solution for the long term, and not use the bad behavior of transition technology as a justification for allowing the solution to continue to be broken once the transition technology is no longer in use.

There is bad behavior only if misused.
Instability of IPv4 addresses isn't a property of 6rd, just one of IPv4-service characteristic.

RD

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Feb 2012 13:37:17 +0000

On Feb 23, 2012, at 3:26 AM, Rémi Després <[email-masked]<mailto:[email-masked]>>
 wrote:
Even if it doesn't, it isn't a serious problem: the host is informed in ICMPv6 that unreachability of the destination is due to ingress or egress filtering (Type 1 code 5 per RFC4443).
What it does next is implementation dependent, but checking its source address makes sense.

This is true, but it leaves the problem of what happens to net-local communication when this happens.   As a reminder, the original point I was making was simply that it is in fact necessary, or at least desirable, to use ULAs for internal communication.

If this is true, it seems like a pretty big problem.   It's bad enough when ISPs change my IP address; now they are going to renumber my entire network?   DHCP has generally been designed to prevent this: when you renew your address, you get the same address, not a different one, and when you renew your prefix, the same is true.

---

From: Rémi Després <[email-masked]>
Date: Thu, 23 Feb 2012 15:07:49 +0100

Le 2012-02-23 à 14:37, Ted Lemon a écrit :

> On Feb 23, 2012, at 3:26 AM, Rémi Després <[email-masked]>
>  wrote:
> This is true, but it leaves the problem of what happens to net-local communication when this happens.

If local communication uses GUAs and, as I suggest, GUAs remain valid in case of WAN-link failure, local communication continues undisrupted.

>  As a reminder, the original point I was making was simply that it is in fact necessary, or at least desirable, to use ULAs for internal communication.

AFAIK, it creates more problems than it solves.
My home site uses IPv6 without ULAs. It has no problem, and I don't know how I could use ULAs today if I wanted to.

Wanting to use ULA it in my understanding against the keep-it-simple principle.

> If this is true, it seems like a pretty big problem.   It's bad enough when ISPs change my IP address; now they are going to renumber my entire network?  

At least on a single-link, changing an IPv6 prefix isn't more complex than changing the external address of a NAT44: It breaks current connections but everything else is automatically fixed.

For instance, when Free obtained a /26 instead of its initial /32, in 2008, my IPv6 prefix changed but I didn't notice it before examining which IPv6 address (GUA) my Mac was using. 

> DHCP has generally been designed to prevent this: when you renew your address, you get the same address, not a different one, and when you renew your prefix, the same is true.

If I get it right, you assume that each host has both a ULA, for local sessions, and a GUA, have Internet e2e transparency.
But, as noticed, not all hosts can do this, so that this model less workable than the current one where only GUAs are used.

RD

---

From: Wuyts Carl <[email-masked]>
Date: Thu, 23 Feb 2012 15:15:17 +0100

Well, you have people pro and contra ULA-support.  Lots of people question the real need for ULA as well.
I tend to agree you don't really need it, at least not in the most common deployments (we're mainly doing residential CPEs), although our CPE supports it today (configurable).  It indeed adds a little extra complexity, as you get more and more addresses.  In a residential scenario, you often only have 1 LAN segment, hence the need for ULA becomes less important I guess.

It's there for people who want to use it, I guess, and can be maybe useful in some more advanced roll-outs or future home-net solutions with multiple LAN segments in the home.  As we're deploying in a managed CPE, it's up to our customer to either enable or not the ULA creation on the advertising interface(s).

Regs
Carl

From: [email-masked] [mailto:[email-masked]] On Behalf Of Rémi Després
Sent: donderdag 23 februari 2012 15:08
To: Ted Lemon
Cc: [email-masked]; [email-masked]
Subject: Re: [v6ops] 6204bis and WAN disappearing

RD

---

From: Rémi Després <[email-masked]>
Date: Thu, 23 Feb 2012 15:29:56 +0100

Le 2012-02-23 à 15:15, Wuyts Carl a écrit :

> I tend to agree you don’t really need it, at least not in the most common deployments (we’re mainly doing residential CPEs), although our CPE supports it today (configurable).  It indeed adds a little extra complexity, as you get more and more addresses.  In a residential scenario, you often only have 1 LAN segment, hence the need for ULA becomes less important I guess.
>  
> It’s there for people who want to use it, I guess, and can be maybe useful in some more advanced roll-outs or future home-net solutions with multiple LAN segments in the home.  As we’re deploying in a managed CPE, it’s up to our customer to either enable or not the ULA creation on the advertising interface(s).

Right.
Thanks,
RD

---

From: Ralph Droms <[email-masked]>
Date: Thu, 23 Feb 2012 14:32:50 +0000

I would be interested to hear from anyone who has any experience with current IPv6 host implementations and the scenarios we are discussing here: specifically:

* ULA prefix with GUA advertised only when WAN connectivity is operable.  What happens when the availability of the GUA flaps?  Do hosts operate as expected and continue to communicate with other hosts using the ULA prefixes?  Are any problems attributable to implementation issues or are there protocol problems?
* GUA with no ULA and a flash changeover when the WAN link comes back up.  How are the RAs manipulated and is it possible to cause all hosts to switch to the new prefix immediately?

- Ralph

---

From: Timothy Winters <[email-masked]>
Date: Thu, 23 Feb 2012 09:51:05 -0500

Hi Ralph,

> * ULA prefix with GUA advertised only when WAN connectivity is operable.  What happens when the availability of the GUA flaps?  Do hosts operate as expected and continue to communicate with other h…
We haven't tried the first scenario at the CE Events yet, but we are holding an event in April and I will make sure to try this out.  I will report back to v6ops with what we find.
> * GUA with no ULA and a flash changeover when the WAN link comes back up.  How are the RAs manipulated and is it possible to cause all hosts to switch to the new prefix immediately?
If the CE Router is not rebooted, it will transmit Router Advertisements with the new prefix and set the valid lifetime to 0 on the deprecated prefix.  Most host implementations that we have used will properly deprecate the old prefix and not use it for new sessions.

Regards,
Tim

---

From: Rémi Després <[email-masked]>
Date: Thu, 23 Feb 2012 16:24:17 +0100

Hello Ralph,

> * ULA prefix with GUA advertised only when WAN connectivity is operable.  What happens when the availability of the GUA flaps?  Do hosts operate as expected and continue to communicate with other h…

No personal experience with this.

> * GUA with no ULA and a flash changeover when the WAN link comes back up.  How are the RAs manipulated and is it possible to cause all hosts to switch to the new prefix immediately?

1. If a host attempts to establish an outgoing session before having noticed the newly advertised WAN prefix, it will normally get an ICMPv6 error message with Type 1 and Code 5 (unreachable destination due to ingress or egress filtering).
- This message should be returned by the CPE, and if not by the ISP network.
- When this host receives an RA with the new prefix, be it solicited or not, everything is normal again. 

2. I have no experience of local IPv6 sessions that would have existed in case of WAN link failure. Yet, it is clear that using the last global prefix as a local prefix until the link comes back provides a better service in this respect than switching to a new prefix, with no known drawback AFAIAC.

3. The need to CHANGE addresses after the WAN link comes back should remain exceptional. 
- In my personal experience, it happened only once in more than 4 years.
- I have no count of WAN link outages, but I know that it is much larger than just one (DSL cable unplugged ...). 

Regards,
RD

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Feb 2012 21:07:54 +0000

On Feb 23, 2012, at 9:32 AM, Ralph Droms <[email-masked]<mailto:[email-masked]>>
 wrote:
* ULA prefix with GUA advertised only when WAN connectivity is operable.  What happens when the availability of the GUA flaps?  Do hosts operate as expected and continue to communicate with other hosts using the ULA prefixes?  Are any problems attributable to implementation issues or are there protocol problems?

Linux and OSX both seem to support this correctly, at least according to the brief test I just did.   Both operating systems use the ULA source address when attempting to communicate with a destination address that uses the same prefix.   I don't have a windows box here to test it on, but I don't see any reason to think they get it wrong.

One slight concern about the Linux implementation is that the ULA is marked as global in ifconfig; I don't know whether this is a kernel bug or an ifconfig bug, and I've only tried it on Ubuntu Meerkat, so I don't have a broad sample to work from.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Feb 2012 10:21:56 +1300

On 2012-02-24 10:07, Ted Lemon wrote:
...

> One slight concern about the Linux implementation is that the ULA is marked as global in ifconfig; I don't know whether this is a kernel bug or an ifconfig bug, and I've only tried it on Ubuntu Mee…

What bug? ULAs are *defined* as global.

   Brian

---

From: Mark Andrews <[email-masked]>
Date: Fri, 24 Feb 2012 08:34:40 +1100

I've been using ULA + GUA for a couple of years now.  It works with
FreeBSD, Mac OS 10.[67], Windows XP and Windows Vista.  My machines
are using a HE's whitelisted resolvers so I get Googles AAAA records
as well as work's AAAA records.  The border router is configured to
send ICMPv6 messages if a ULA source address is used on a outbound
packet.

The longest match rule, fortuitously, works to select the correct
source address (F != 2).  The default address selection rules do
need to be made aware of ULA address and to prefer ULA/48 over GUA
over ULA/7.  ULA address *will* leak and the default address selection
rules need to handle such leakages.  With properly configured address
selection rules the internal comunication mostly uses ULA addresses.

We do need a mechanism so that CPE connected to a ISP can be made
aware that the upstream interface is *not* part of site.  A DHCP /
RA option, annouced by the ISP, would do this nicely perhaps with
a AS number or other unique identifier so that multiple upstream
from the same ISP can be identified.

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Feb 2012 21:43:35 +0000

On Feb 23, 2012, at 4:21 PM, Brian E Carpenter <[email-masked]<mailto:[email-masked]>> wrote:
What bug? ULAs are *defined* as global.

Heh, I suppose you're right.   Globally unique, despite not being globally routed.

---

From: james woodyatt <[email-masked]>
Date: Thu, 23 Feb 2012 16:15:49 -0800

> Heh, I suppose you're right.   Globally unique, despite not being globally routed.

I wish people would remember that even this isn't true.  The ULA addresses are globally unique and are globally routable by private bilateral agreement.  The prohibition in the specification is only against routing them in the public Internet default free zone.  Think of it as IETF saying to the global public Internet transit operators: "All these unicast address prefixes are yours except fc00::/7; attempt no advertisements there."

I hope I don't need to explain the importance of this point.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Ted Lemon <[email-masked]>
Date: Fri, 24 Feb 2012 02:25:40 +0000

On Feb 23, 2012, at 7:15 PM, james woodyatt <[email-masked]<mailto:[email-masked]>> wrote:
globally routable by private bilateral agreement

That's not what "globally" means, or at least not what I mean when I say it.   Globally means reachable from anywhere on the globe.   If a private bilateral agreement is required to reach the ULA, it's not globally reachable.

The Star Child will destroy the earth if we disobey?

Seriously, if your point is that these addresses have to be globally unique, we already covered that.   If your point is that they *could* wind up being routed to anywhere, I think we covered that.   If you have some additional point to make, I'm curious what it is, although no doubt everybody else is holding their fingers in their ears by this point and yelling "shut up shut up shut up!!!"

:)

---

From: Rémi Després <[email-masked]>
Date: Fri, 24 Feb 2012 09:48:05 +0100

Hello Mark,

Thanks for this information.
More in line.

Le 2012-02-23 à 22:34, Mark Andrews a écrit :

> FreeBSD, Mac OS 10.[67], Windows XP and Windows Vista.

You are clearly a more sophisticated user of these OSes than I am.

With Mac OS 10.6.8, I just enabled IPv6 with automatic address configuration.

The fact that my displayed "IPv6 address" is singular doesn't prove, I must admit, that the OS wouldn't handle a ULA if provided a ULA prefix..
To check it, I would have needed a network where RAs announce GUA+ULA, which isn't the case. 
  
> My machines

Is this configuration available by default in common OSes, or is it something you had to configure or some of them (in which case which ones)?

> aware that the upstream interface is *not* part of site.

Well, that could be nice to have, but, I see no important difference between unreachability due to a local WAN link and unreachability due to a remote link).
IMHO, we can live without such a mechanism, and therefore don't need that ULAs indirectly provide this information.

The idea that, thanks to IPv6, each interface can again have a universal address, and can this address can be used to communicate with all other hosts seems to me the kind of simple idea that shouldn't be abandoned for ordinary users. 

Regards,
RD

>  A DHCP /

---

From: Ralph Droms <[email-masked]>
Date: Fri, 24 Feb 2012 09:50:15 +0000

On Feb 23, 2012, at 9:07 PM 2/23/12, Ted Lemon wrote:

> On Feb 23, 2012, at 9:32 AM, Ralph Droms <[email-masked]>
>  wrote:

Excellent.  So, presumably, if the GUA prefix is withdrawn (advertised with lifetimes of 0?) from the RAs, Linux and OS X will continue to communicate with other hosts using the same ULA.  Did you happen to actually try the experiment?

Anyone have experience with dedicated devices like a webcam, printer, NAS?

- Ralph

---

From: [email-masked]
Date: Fri, 24 Feb 2012 11:06:51 +0100

Hi folks,

>>> * ULA prefix with GUA advertised only when WAN connectivity 
>is operable.  What happens when the availability of the GUA 
>flaps?  Do hosts operate as expected and continue to 
>communicate with other hosts using the ULA prefixes?  Are any 
>problems attributable to implementation issues or are there 
>protocol problems?
>> 
>> Linux and OSX both seem to support this correctly, at least 
>according to the brief test I just did.   Both operating 
>systems use the ULA source address when attempting to 
>communicate with a destination address that uses the same 
>prefix.   I don't have a windows box here to test it on, but I 
>don't see any reason to think they get it wrong.
>
>Excellent.  So, presumably, if the GUA prefix is withdrawn 
>(advertised with lifetimes of 0?) from the RAs, Linux and OS X 
>will continue to communicate with other hosts using the same 
>ULA.  Did you happen to actually try the experiment?

I run a similar setup at home for over one year now. In addtition to that we also use Windows XP and 7 machines. I can only say that I saw the above described behaviour when I looked closly at it. During normal operation we had no major impact by using ULAs at home. Local network communication (I have localy delivered web and mail), if it uses IPv6, utilizes ULA. If the GUA disappears (which was the case 2 or 3 times) local communcation continues to run stable.

>Anyone have experience with dedicated devices like a webcam, 

Unfortunatley, I don't have such devices with IPv6 support.

cheers,
Christian Hahn

----------------------------------
T-Systems International GmbH
Supervisory Board: René Obermann (Chairman)
Board of Management: Reinhard Clemens (Chairman), Dr. Ferri Abolhassan, Olaf Heyden, Joachim Langmack, Georg Pepping, Klaus Werner
Commercial register: Amtsgericht Frankfurt am Main HRB 55933
Registered office: Frankfurt am Main
WEEE-Reg.-No. DE87523644
>
>- Ralph
>
>> One slight concern about the Linux implementation is that 
>the ULA is marked as global in ifconfig; I don't know whether 
>this is a kernel bug or an ifconfig bug, and I've only tried 
>it on Ubuntu Meerkat, so I don't have a broad sample to work from.
>

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Fri, 24 Feb 2012 07:36:03 -0600

Hi Christian ,

> described behaviour when I looked closly at it. During normal operation we
> had no major impact by using ULAs at home. Local network communication (I
> have localy delivered web and mail), if it uses IPv6, utilizes ULA. If the GUA

What's causing them to prefer ULA for local communication when GUA is available? 

Is the locally delivered web/mail destination IP address (i.e. ULA) is hardcoded on the source devices (or some DNS muck-up)?

Cheers,
Rajiv

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of [email-masked]
> Sent: Friday, February 24, 2012 5:07 AM
> To: Ralph Droms (rdroms); [email-masked]
> I run a similar setup at home for over one year now. In addtition to that we
> also use Windows XP and 7 machines. I can only say that I saw the above
> described behaviour when I looked closly at it. During normal operation we
> had no major impact by using ULAs at home. Local network communication (I
> have localy delivered web and mail), if it uses IPv6, utilizes ULA. If the GUA
> disappears (which was the case 2 or 3 times) local communcation continues
> to run stable.
> 
> >
> Board of Management: Reinhard Clemens (Chairman), Dr. Ferri Abolhassan,
> Olaf Heyden, Joachim Langmack, Georg Pepping, Klaus Werner

---

From: [email-masked]
Date: Fri, 24 Feb 2012 15:16:34 +0100

Hi Rajiv

>Hi Christian ,
>
>> described behaviour when I looked closly at it. During normal 
>> operation we had no major impact by using ULAs at home. 
>Local network 
>> communication (I have localy delivered web and mail), if it 
>uses IPv6, 
>> utilizes ULA. If the GUA
>
>Is the locally delivered web/mail destination IP address (i.e. 
>ULA) is hardcoded on the source devices (or some DNS muck-up)?

Yes, forgot to mention that I run an internal DNS myself and "internal services" have both, ULA and GUA AAAA entries.

cheers,
Christian
>> >is operable.  What happens when the availability of the GUA flaps?  
>> >Do hosts operate as expected and continue to communicate with other 
>> >hosts using the ULA prefixes?  Are any problems attributable to 
>> >implementation issues or are there protocol problems?
>> >>
>> >systems use the ULA source address when attempting to communicate 
>> >with a destination address that uses the same
>> >(advertised with lifetimes of 0?) from the RAs, Linux and OS X will 
>> >continue to communicate with other hosts using the same 
>ULA.  Did you 
>> I run a similar setup at home for over one year now. In addtition to 
>> that we also use Windows XP and 7 machines. I can only say 
>that I saw 
>> the above described behaviour when I looked closly at it. During 
>> normal operation we had no major impact by using ULAs at home. Local 
>> network communication (I have localy delivered web and mail), if it 
>> uses IPv6, utilizes ULA. If the GUA disappears (which was the case 2 
>> or 3 times) local communcation continues to run stable.
>> 
>> >
>> >Anyone have experience with dedicated devices like a 
>webcam, printer, 
>> >NAS?
>> 
>> Supervisory Board: René Obermann (Chairman) Board of Management: 
>> Reinhard Clemens (Chairman), Dr. Ferri Abolhassan, Olaf Heyden, 
>> Joachim Langmack, Georg Pepping, Klaus Werner Commercial register: 
>> Amtsgericht Frankfurt am Main HRB 55933 Registered office: Frankfurt 
>> am Main WEEE-Reg.-No. DE87523644
>> >
>> >- Ralph
>> >
>> >the ULA is marked as global in ifconfig; I don't know 
>whether this is 
>> >a kernel bug or an ifconfig bug, and I've only tried it on Ubuntu 
>> >Meerkat, so I don't have a broad sample to work from.
>> >

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 24 Feb 2012 17:35:59 +0000

> RA option, announced by the ISP, would do this nicely perhaps with

I think this (the DHCPv6 option, not RA) is an interesting suggestion to explore. But instead of indicating what scope the upstream interface is *not* a part of, I think it might be better to indicate the lowest level multicast scope it *is* a part of. It would be reasonable to expect ISPs to indicate "global scope". 

But a CE router could be configured or defaulted to send a lower (site or organization) scope from its own DHCPv6 server. 

Given that multiple specs (e.g., REC-2 of RFC 6092) tell CE routers not to send org scope or lower out the WAN interface, by default, such a DHCPv6 option used by CE routers on their LAN interfaces might provide a useful way to help cascaded routers understand that they are not at the LAN boundary, and make it easier to create a working multicast environment in a multi-router home network.

I guess this would need to be something for dhcwg and homenet to consider, though. 
Barbara

---

From: Ole Trøan <[email-masked]>
Date: Fri, 24 Feb 2012 18:46:28 +0100

> I guess this would need to be something for dhcwg and homenet to consider, though. 

border discovery is being worked on in homenet.

cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 25 Feb 2012 08:49:06 +1300

> What's causing them to prefer ULA for local communication when GUA is available? 

Longest match, since a ULA *is* a GUA.

   Brian