Subject: [homenet] #4: Use of ULAs

From: "homenet issue tracker" <[email-masked]>
Date: Wed, 21 Mar 2012 23:33:00 -0000

#4: Use of ULAs

 CN1 in the -02 text says ULAs should be provisioned by default.  Do we
 agree?  And if so, should they be preferred over globals?  The new
 3484-bis has changed so they are not *unless* a specific /48 for the site
 is added to the 3484 policy table with higher precedence than globals. We
 should design something that works when disconnected from the Internet.
 Also, we currently say nothing about ULA-only devices and their
 reachability from outside the homenet; do we want to?

-- 
-------------------+---------------------------------------
 Reporter:  tjc@…  |      Owner:  draft-ietf-homenet-arch@…
     Type:  task   |     Status:  new
 Priority:  major  |  Milestone:
Component:  arch   |    Version:
 Severity:  -      |   Keywords:
-------------------+---------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/homenet/trac/ticket/4>
homenet <http://tools.ietf.org/homenet/>

---

From: Ray Hunter <[email-masked]>
Date: Thu, 22 Mar 2012 14:49:43 +0100

As requested by Tim: My comments on ULA use in Homenet posted in 
consolidated manner to the issue tracker.

I think Homenet still has a lot of work to do, especially due to the 
autoconfig requirements.

Everyone wants autoconfig.

Concurrent ULA + PA + both with autoconfig + invariant addresses is 
likely going to be tough, if not downright impossible.

So why do we think we really need concurrent ULA+PA in Homenet as a base 
requirement? I'm not entirely convinced yet.

Issue 1: One reason ULA seems to be mentioned is "time-invariance of 
addressing for use by sensor networks."

Using the example of an electrician setting up a sensor network in a 
home before an ISP is present, and expecting time-invariant ULA 
addresses. Firstly, the electrician would have to generate a Global ID 
for ULA when the lights are installed. The electrician can generate a  
unique Global ID (and hence the /48 prefix of ULA) using the procedure 
in RFC4193.

Problems with this are:
1) The /48 ULA prefix is tied to a time (when the electrician pressed 
the "generate ULA" button)
If a user regenerates the ULA prefix later, the algorithm will generate 
a different /48 prefix: all addresses in the house will change

2) The /48 ULA prefix is tied to a MAC address (of the router or device 
used to seed the ULA prefix generation algorithm)
If a user changes router hardware, the /48 prefix will change. Or else 
the seed stored in non-volatile memory will be lost when hardware is 
replaced. Again all addresses in the house will change

3) The Global ID portion of the ULA has to be manually assigned to each 
of the routers (if there's more than one) as there's no mechanism to 
distribute Global IDs today.
Homenet needs autoconfiguration.

4) Even if the /48 prefix is made invariant, the /64 LAN prefix 
generated from it probably won't be invariant as hardware is added, 
replugged or removed.
Again, OK for manual configuration like an enterprise network, but 
Homenet wants autoconfig.

I don't see how "complete time-invariance of addressing"  is achievable 
together with autoconfig, even if we call for an equivalent site-local 
addressing with a fixed /48 prefix that is common to all Homenet 
implementations everywhere. We've been down that rathole before. 
Site-local has been deprecated in RFC3879. And realistically speaking, 
any time someone replaces or adds or re-plugs any router hardware, the 
LAN's /64 prefix will change when using autoconfig.

I think it would be useful for the Homenet WG to propose a scheme for 
sensor networks to be able to maintain simple peerings despite the 
presence of time-variant addressing [whether these are ULA, PA, PI, IPv4 
or whatever]. In fact, it would seem to me that a peering solution 
should use something that is long-term invariant as an identifier for 
keying the peering e.g. EUI-64 a.k.a. MAC BIA or DHCP DUID, and not the 
IPv6 address at all. The invariant identifier could be automatically 
registered by each sensor as a name in the Homenet naming service. Peers 
could resolve that name to the current IPv6 address and then verify the 
peering using their own protocol like HMAC_MD5 with a shared secret 
(RFC2104). Loss of connection would trigger a new address resolution, 
reconnection, and peer check. Agreeing the shared secret is peering 
specific (and has to be solved anyway even with fixed addresses). I have 
an asterisk hardware phone that does something similar to this, so it 
can't require much code.

Issue 2: Use of multiple ULA Global ID's in Homenet may also cause 
problems with source address selection (3484-revise). There is no way to 
know which ULA's are connected to the local Homenet, and which are 
distributed on remote Homenets spread over the Internet. This causes 
problems with potential ULA leakage, and in determining priority between 
PA-derived addresses and ULA addresses when both are available and the 
default 3484 or 3484-revise rules are followed.

A workaround might be to be redistribute a non-default RFC3484-revise 
policy table to all end nodes via draft-fujisaki-dhc-addr-select-opt-07, 
but its not clear that all end nodes will support this mechanism, nor 
how the contents of the policy table would be managed in a distributed 
and automated manner.

Issue 3: A reason concurrent ULA+PA seems to be required was that 
"intra-homenet communication should survive a long term ISP outage, and 
must be able to be established without any ISP connection present."

The first linkage would appear to be when ISP PA-derived prefixes within 
Homenet timeout via DHCPv6 PD meaning that a long-running session based 
on this address would drop. That has nothing directly to do with ULA, 
and may have other solutions.

Question: How long are ISP's setting their DHCPv6 PD timers in practice? 
Simply recommending very long timers for the DHCPv6 PD PA-derived prefix 
might be a practical solution. How often has your ISP connection been 
down for say 10 days?

Another solution might be for the application to reconnect using another 
PA-derived address (if the user has two providers).

The second linkage may also have other solutions, such as only 
configuring a ULA prefix when no PA-derived prefixes are present.

That would mean at any one time the Homenet could potentially be running 
either ULA or multiple PA, but not both, which completely avoids any 
address selection conflicts and having to redistribute new RFC3484 
address selection rules to all nodes. Simply put: "Please reboot or 
reconnect to fix any problems."

regards,
RayH

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 23 Mar 2012 11:50:07 +1300

On 2012-03-22 12:33, homenet issue tracker wrote:
>  agree?  

Yes, by the CER (MUST).

It's much less clear for all other routers on site. I would prefer that
no other router provisions a ULA prefix if the CER has already delegated
one.

>  And if so, should they be preferred over globals?

Yes.

>  The new

We'll have to deal with whatever 3484bis ends up saying. If it does
require an explicit policy table entry table, that will require
a mechanism, associated with the prefix delegation mechanism.

>  reachability from outside the homenet; do we want to?

I don't see what there is to say; they aren't reachable, and that's
a feature.

   Brian

---

From: Jari Arkko <[email-masked]>
Date: Tue, 27 Mar 2012 22:01:56 +0200

I fully agree with these comments from Ray. Basically, when hardware changes on some router it is pretty much given that some address will change somewhere. And I don't think fully stable addressing is a good goal to begin with. Make the devices survive addressing changes, and we'll be fine.

Initial ULA generation before any connectivity with the Internet can be reached is fine, however.

Jari

On 22.03.2012 14:49, Ray Hunter wrote:
> As requested by Tim: My comments on ULA use in Homenet posted in consolidated manner to the issue tracker.
>
> I think Homenet still has a lot of work to do, especially due to the autoconfig requirements.
>
> Concurrent ULA + PA + both with autoconfig + invariant addresses is likely going to be tough, if not downright impossible.
>
> So why do we think we really need concurrent ULA+PA in Homenet as a base requirement? I'm not entirely convinced yet.
>
>
> Issue 1: One reason ULA seems to be mentioned is "time-invariance of addressing for use by sensor networks."
>
> Using the example of an electrician setting up a sensor network in a home before an ISP is present, and expecting time-invariant ULA addresses. Firstly, the electrician would have to generate a Global ID for ULA when the lights are installed. The electrician can generate a  unique Global ID (and hence the /48 prefix of ULA) using the procedure in RFC4193.
>
> Problems with this are:
> 1) The /48 ULA prefix is tied to a time (when the electrician pressed the "generate ULA" button)
> If a user regenerates the ULA prefix later, the algorithm will generate a different /48 prefix: all addresses in the house will change
>
> 2) The /48 ULA prefix is tied to a MAC address (of the router or device used to seed the ULA prefix generation algorithm)
> If a user changes router hardware, the /48 prefix will change. Or else the seed stored in non-volatile memory will be lost when hardware is replaced. Again all addresses in the house will change
>
> 3) The Global ID portion of the ULA has to be manually assigned to each of the routers (if there's more than one) as there's no mechanism to distribute Global IDs today.
> 4) Even if the /48 prefix is made invariant, the /64 LAN prefix generated from it probably won't be invariant as hardware is added, replugged or removed.
> Again, OK for manual configuration like an enterprise network, but Homenet wants autoconfig.
>
> I don't see how "complete time-invariance of addressing"  is achievable together with autoconfig, even if we call for an equivalent site-local addressing with a fixed /48 prefix that is common to all Homenet implementations everywhere. We've been down that rathole before. Site-local has been deprecated in RFC3879. And realistically speaking, any time someone replaces or adds or re-plugs any router hardware, the LAN's /64 prefix will change when using autoconfig.
>
>
> I think it would be useful for the Homenet WG to propose a scheme for sensor networks to be able to maintain simple peerings despite the presence of time-variant addressing [whether these are ULA, PA, PI, IPv4 or whatever]. In fact, it would seem to me that a peering solution should use something that is long-term invariant as an identifier for keying the peering e.g. EUI-64 a.k.a. MAC BIA or DHCP DUID, and not the IPv6 address at all. The invariant identifier could be automatically registered by each sensor as a name in the Homenet naming service. Peers could resolve that name to the current IPv6 address and then verify the peering using their own protocol like HMAC_MD5 with a shared secret (RFC2104). Loss of connection would trigger a new address resolution, reconnection, and peer check. Agreeing the shared secret is peering specific (and has to be solved anyway even with fixed addresses). I have an asterisk hardware phone that does something similar to this, so it can't 
> require much code.
>
>
>
>
> Issue 2: Use of multiple ULA Global ID's in Homenet may also cause problems with source address selection (3484-revise). There is no way to know which ULA's are connected to the local Homenet, and which are distributed on remote Homenets spread over the Internet. This causes problems with potential ULA leakage, and in determining priority between PA-derived addresses and ULA addresses when both are available and the default 3484 or 3484-revise rules are followed.
>
> A workaround might be to be redistribute a non-default RFC3484-revise policy table to all end nodes via draft-fujisaki-dhc-addr-select-opt-07, but its not clear that all end nodes will support this mechanism, nor how the contents of the policy table would be managed in a distributed and automated manner.
>
>
> Issue 3: A reason concurrent ULA+PA seems to be required was that "intra-homenet communication should survive a long term ISP outage, and must be able to be established without any ISP connection present."
>
> The first linkage would appear to be when ISP PA-derived prefixes within Homenet timeout via DHCPv6 PD meaning that a long-running session based on this address would drop. That has nothing directly to do with ULA, and may have other solutions.
>
> Question: How long are ISP's setting their DHCPv6 PD timers in practice? Simply recommending very long timers for the DHCPv6 PD PA-derived prefix might be a practical solution. How often has your ISP connection been down for say 10 days?
>
> Another solution might be for the application to reconnect using another PA-derived address (if the user has two providers).
>
>
> The second linkage may also have other solutions, such as only configuring a ULA prefix when no PA-derived prefixes are present.
>
> That would mean at any one time the Homenet could potentially be running either ULA or multiple PA, but not both, which completely avoids any address selection conflicts and having to redistribute new RFC3484 address selection rules to all nodes. Simply put: "Please reboot or reconnect to fix any problems."
>
>
> regards,
> RayH
>
>
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
>

---

From: Dave Taht <[email-masked]>
Date: Tue, 27 Mar 2012 13:21:45 -0700

On Tue, Mar 27, 2012 at 1:01 PM, Jari Arkko <[email-masked]> wrote:

> I fully agree with these comments from Ray. Basically, when hardware
> changes on some router it is pretty much given that some address will
> change somewhere. And I don't think fully stable addressing is a good goal
> to begin with. Make the devices survive addressing changes, and we'll be
> fine.
>
While I agree that having a ULA at the getgo is a goodness, following
RFC4193 to the letter is very difficult.

1) You need time. If you do not have a battery backed up clock in the
device (set to an appropriate value), you need to get time from the
internet, which you can't do until you are on the internet.

Or you could mandate time come from a gps.

If you are getting time from the internet, you need sntp, ntp, or
equivalent. From gps, something like chronyd.

Without this, generating the ULA is generally going to come from 'time
since the epoch or build date', and other sorts of randomness would be
useful.

2) The infrastructure mandated by that RFC requires a sha-1 digest. Many
devices (at least at present) do not come with a SSL based infrastructure
from which that is a single function thereof.

3) It is my hope that hardware based RNGs start showing up soon in many
more devices. But thus far, no luck, so finding an essential source of
randomness would be good.

4) Lastly, without a solid means of getting the ULA and a human usable name
out to the users's dns system (be that mdns, normal dns, etc), there is no
way to map the idea of that number to a presentation that a user can 'just
use'. I could be humorous about this (As april 1st is coming up) - flashing
the blinking lights on a switch or router in baudot code might suffice for
some, but...

>> Using the example of an electrician setting up a sensor network in a home
>> before an ISP is present, and expecting time-invariant ULA addresses.
>> Firstly, the electrician would have to generate a Global ID for ULA when
>> the lights are installed. The electrician can generate a  unique Global ID
>> (and hence the /48 prefix of ULA) using the procedure in RFC4193.
>>
>> Problems with this are:
>> If a user regenerates the ULA prefix later, the algorithm will generate a
>> different /48 prefix: all addresses in the house will change
>>
>> 4) Even if the /48 prefix is made invariant, the /64 LAN prefix generated
>> from it probably won't be invariant as hardware is added, replugged or
>> removed.
>> implementations everywhere. We've been down that rathole before. Site-local
>> has been deprecated in RFC3879. And realistically speaking, any time
>> someone replaces or adds or re-plugs any router hardware, the LAN's /64
>> prefix will change when using autoconfig.
>>
>>
>> sensor networks to be able to maintain simple peerings despite the presence
>> of time-variant addressing [whether these are ULA, PA, PI, IPv4 or
>> whatever]. In fact, it would seem to me that a peering solution should use
>> something that is long-term invariant as an identifier for keying the
>> peering e.g. EUI-64 a.k.a. MAC BIA or DHCP DUID, and not the IPv6 address
>> at all. The invariant identifier could be automatically registered by each
>> sensor as a name in the Homenet naming service. Peers could resolve that
>> name to the current IPv6 address and then verify the peering using their
>> own protocol like HMAC_MD5 with a shared secret (RFC2104). Loss of
>> connection would trigger a new address resolution, reconnection, and peer
>> check. Agreeing the shared secret is peering specific (and has to be solved
>> anyway even with fixed addresses). I have an asterisk hardware phone that
>> does something similar to this, so it can't require much code.
>>
>>
>>
>>
>> policy table to all end nodes via draft-fujisaki-dhc-addr-**select-opt-07,
>> but its not clear that all end nodes will support this mechanism, nor how
>> the contents of the policy table would be managed in a distributed and
>> automated manner.
>>
>>
>> Homenet timeout via DHCPv6 PD meaning that a long-running session based on
>> this address would drop. That has nothing directly to do with ULA, and may
>> have other solutions.
>>
>> might be a practical solution. How often has your ISP connection been down
>> for say 10 days?
>>
>> address selection conflicts and having to redistribute new RFC3484 address
>> selection rules to all nodes. Simply put: "Please reboot or reconnect to
>> fix any problems."
>>
>>
>> regards,
>> RayH
>>
>>
>>>  ______________________________**_________________
>> homenet mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/homenet<https://www.ietf.org/mailman/listinfo/homenet>
>>
>>
>
> ______________________________**_________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/homenet<https://www.ietf.org/mailman/listinfo/homenet>
>

-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net

---

From: Dave Taht <[email-masked]>
Date: Tue, 27 Mar 2012 13:28:04 -0700

> no other router provisions a ULA prefix if the CER has already delegated

Since it is nearly impossible to learn a subnet prefix that is unused
unless all devices share a routing protocol, I have generally preferred to
generate unique ULAs per routing device.

> >  And if so, should they be preferred over globals?
This part I don't quite understand. I would prefer global prefixes to
always take precedence over ULAs.
I'd like ULAs to try to talk only to ULAs. ULAs should not escape into the
global DNS, but should end up in local dns.

Even with 'happy eyeballs', having a means to disable a ULA -> global
connection by default saves 100s of ms in the bad cases.

> a mechanism, associated with the prefix delegation mechanism.

OK, I will re-read, thx for the update..

---

From: Thomas Herbst <[email-masked]>
Date: Tue, 27 Mar 2012 14:12:22 -0700

"Fully stable" would be static and I don't think anyone is suggesting
static.  While devices must be able to survive address changes, they
should not have to change addresses frequently.

Using ULA's and the availability of Global addressing are orthogonal
issues. 

ULA's are the new Link Local's in a routed home.

tom

On 3/27/12 1:01 PM, "Jari Arkko" <[email-masked]> wrote:

>change somewhere. And I don't think fully stable addressing is a good
>goal to begin with. Make the devices survive addressing changes, and
>we'll be fine.
>
>> So why do we think we really need concurrent ULA+PA in Homenet as a
>>base requirement? I'm not entirely convinced yet.
>>
>>
>>can't 
>> The first linkage would appear to be when ISP PA-derived prefixes
>>within Homenet timeout via DHCPv6 PD meaning that a long-running session
>>based on this address would drop. That has nothing directly to do with
>>ULA, and may have other solutions.
>>
>> Question: How long are ISP's setting their DHCPv6 PD timers in
>>practice? Simply recommending very long timers for the DHCPv6 PD
>>PA-derived prefix might be a practical solution. How often has your ISP
>>connection been down for say 10 days?
>>
>> Another solution might be for the application to reconnect using
>>another PA-derived address (if the user has two providers).
>>
>>
>> That would mean at any one time the Homenet could potentially be
>>running either ULA or multiple PA, but not both, which completely avoids
>>any address selection conflicts and having to redistribute new RFC3484

---

From: Jari Arkko <[email-masked]>
Date: Tue, 27 Mar 2012 23:13:24 +0200

Not sure if this is on or off-topic for this working group but here's a recent extension to my home network setup:

http://thingsonip.blogspot.fr/2012/03/smart-igloos.html

Jari

---

From: Ray Bellis <[email-masked]>
Date: Tue, 27 Mar 2012 21:20:37 +0000

> should not have to change addresses frequently.

<nohat>

How often is "frequently"?

I know of at least one ISP who gives a _dynamic_ /64 to every DSL customer that happens to negotiate IP6CP that changes each time they connect.

> Using ULA's and the availability of Global addressing are orthogonal

+1

Ray

---

From: Thomas Herbst <[email-masked]>
Date: Tue, 27 Mar 2012 14:50:28 -0700

If you change routing equipment, perhaps even upgrade firmware,  changing
ULA's can be fair game.
An instance of the same hardware in the same configuration should have no
reason to randomly change ULA addressing.

The discussion of GUA's still orthogonal.  It doesn't matter what the ISP
policy is if I don't connect, they provide a small chunk of address like a
/64, the connection is flaky or broken, I stop paying the bill,or for any
other reason I don't have connectivity, I should still be able to have a
stable connection across the routed home.

In the bridged home this now happens every day with LL's.

tom

On 3/27/12 2:20 PM, "Ray Bellis" <[email-masked]> wrote:

>I know of at least one ISP who gives a _dynamic_ /64 to every DSL
>customer that happens to negotiate IP6CP that changes each time they
>connect.
>

---

From: Jim Gettys <[email-masked]>
Date: Tue, 27 Mar 2012 18:40:31 -0400

I'd like to drag this back to Dave's points 1-4.  There are real
implementation issues with RFC4193.  The questions are:
    a) do these problems matter?
    b) if so, what do we do about them?

Note that true random bits are really hard to come by right now in
current home routers.  Sigh...  Anyone who knows any chip architects,
please beat them bloody until they provide a hardware RNG....

So long as the addresses don't leak from the home network, and each home
router settles on unique addresses (maybe derived from their MAC
addresses), I'm not sure it matters.  But someone who has thought longer
and harder about ULA's should think about the issues Dave's raising.
                    - Jim

On 03/27/2012 04:21 PM, Dave Taht wrote:
>
>
> On Tue, Mar 27, 2012 at 1:01 PM, Jari Arkko <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     I fully agree with these comments from Ray. Basically, when
>     hardware changes on some router it is pretty much given that some
>     address will change somewhere. And I don't think fully stable
>     addressing is a good goal to begin with. Make the devices survive
>     addressing changes, and we'll be fine.
>
> 2) The infrastructure mandated by that RFC requires a sha-1 digest.
> Many devices (at least at present) do not come with a SSL based
> infrastructure from which that is a single function thereof.
>
> 3) It is my hope that hardware based RNGs start showing up soon in
> many more devices. But thus far, no luck, so finding an essential
> source of randomness would be good.
>
> 4) Lastly, without a solid means of getting the ULA and a human usable
> name out to the users's dns system (be that mdns, normal dns, etc),
> there is no way to map the idea of that number to a presentation that
> a user can 'just use'. I could be humorous about this (As april 1st is
> coming up) - flashing the blinking lights on a switch or router in
> baudot code might suffice for some, but...
>  
>
>     Jari
>
>
>         As requested by Tim: My comments on ULA use in Homenet posted
>         in consolidated manner to the issue tracker.
>
>         Concurrent ULA + PA + both with autoconfig + invariant
>         addresses is likely going to be tough, if not downright
>         impossible.
>
>         So why do we think we really need concurrent ULA+PA in Homenet
>         as a base requirement? I'm not entirely convinced yet.
>
>
>         Issue 1: One reason ULA seems to be mentioned is
>         "time-invariance of addressing for use by sensor networks."
>
>         Using the example of an electrician setting up a sensor
>         network in a home before an ISP is present, and expecting
>         time-invariant ULA addresses. Firstly, the electrician would
>         have to generate a Global ID for ULA when the lights are
>         installed. The electrician can generate a  unique Global ID
>         If a user regenerates the ULA prefix later, the algorithm will
>         generate a different /48 prefix: all addresses in the house
>         will change
>
>         2) The /48 ULA prefix is tied to a MAC address (of the router
>         or device used to seed the ULA prefix generation algorithm)
>         If a user changes router hardware, the /48 prefix will change.
>         Or else the seed stored in non-volatile memory will be lost
>         when hardware is replaced. Again all addresses in the house
>         will change
>
>         3) The Global ID portion of the ULA has to be manually
>         assigned to each of the routers (if there's more than one) as
>         there's no mechanism to distribute Global IDs today.
>         4) Even if the /48 prefix is made invariant, the /64 LAN
>         prefix generated from it probably won't be invariant as
>         hardware is added, replugged or removed.
>         I don't see how "complete time-invariance of addressing"  is
>         achievable together with autoconfig, even if we call for an
>         equivalent site-local addressing with a fixed /48 prefix that
>         is common to all Homenet implementations everywhere. We've
>         been down that rathole before. Site-local has been deprecated
>         in RFC3879. And realistically speaking, any time someone
>         replaces or adds or re-plugs any router hardware, the LAN's
>         /64 prefix will change when using autoconfig.
>
>
>         I think it would be useful for the Homenet WG to propose a
>         scheme for sensor networks to be able to maintain simple
>         peerings despite the presence of time-variant addressing
>         [whether these are ULA, PA, PI, IPv4 or whatever]. In fact, it
>         would seem to me that a peering solution should use something
>         that is long-term invariant as an identifier for keying the
>         peering e.g. EUI-64 a.k.a. MAC BIA or DHCP DUID, and not the
>         IPv6 address at all. The invariant identifier could be
>         automatically registered by each sensor as a name in the
>         Homenet naming service. Peers could resolve that name to the
>         current IPv6 address and then verify the peering using their
>         own protocol like HMAC_MD5 with a shared secret (RFC2104).
>         Loss of connection would trigger a new address resolution,
>         reconnection, and peer check. Agreeing the shared secret is
>         peering specific (and has to be solved anyway even with fixed
>         addresses). I have an asterisk hardware phone that does
>         something similar to this, so it can't require much code.
>
>
>
>
>         Issue 2: Use of multiple ULA Global ID's in Homenet may also
>         cause problems with source address selection (3484-revise).
>         There is no way to know which ULA's are connected to the local
>         Homenet, and which are distributed on remote Homenets spread
>         over the Internet. This causes problems with potential ULA
>         leakage, and in determining priority between PA-derived
>         addresses and ULA addresses when both are available and the
>         A workaround might be to be redistribute a non-default
>         RFC3484-revise policy table to all end nodes via
>         draft-fujisaki-dhc-addr-select-opt-07, but its not clear that
>         all end nodes will support this mechanism, nor how the
>         contents of the policy table would be managed in a distributed
>         and automated manner.
>
>
>         Issue 3: A reason concurrent ULA+PA seems to be required was
>         that "intra-homenet communication should survive a long term
>         ISP outage, and must be able to be established without any ISP
>         connection present."
>
>         The first linkage would appear to be when ISP PA-derived
>         prefixes within Homenet timeout via DHCPv6 PD meaning that a
>         long-running session based on this address would drop. That
>         has nothing directly to do with ULA, and may have other solutions.
>
>         practice? Simply recommending very long timers for the DHCPv6
>         PD PA-derived prefix might be a practical solution. How often
>         has your ISP connection been down for say 10 days?
>
>         Another solution might be for the application to reconnect
>         using another PA-derived address (if the user has two providers).
>
>
>         That would mean at any one time the Homenet could potentially
>         be running either ULA or multiple PA, but not both, which
>         completely avoids any address selection conflicts and having
>         to redistribute new RFC3484 address selection rules to all
>         nodes. Simply put: "Please reboot or reconnect to fix any
>         problems."
>
>
>         regards,
>         RayH
>
>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Mar 2012 15:09:39 +1300

Dave,

> generate unique ULAs per routing device.

Our two statements are not inconsistent... obviously, if a router comes
up and does not hear about a ULA prefix from another router, it may be
appropriate to generate a new one. But if we have a prefix delegation
mechanism in place, that may be sufficient.

> global DNS, but should end up in local dns.

ULAs should really only be used to talk to ULAs, so when I say 'prefer ULAs',
I mean prefer a pair of ULAs to a pair of globals. In case it isn't clear,
in my mind the problem is always address *pair* selection. So that means
that a host should do something like this in the default case:

  Do I have a ULA?
  If yes, does the other guy have a ULA (in the same prefix)?
    If yes, use the two ULAs.
  Else, use two globals.

I'm hoping 3484bis will result in this.

> connection by default saves 100s of ms in the bad cases.

Agreed.

   Brian

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 27 Mar 2012 20:34:55 -0700

> I'm hoping 3484bis will result in this.

In the general case, you don't believe ula and global should have
communication at all?  Or just a matter of source selection when multiple
address types are available to a given host ?

Cb

> >>>  is added to the 3484 policy table with higher precedence than
globals.
> >> We

---

From: Ray Hunter <[email-masked]>
Date: Wed, 28 Mar 2012 09:44:01 +0200

See below.

Dave Taht wrote:
> On Thu, Mar 22, 2012 at 3:50 PM, Brian E Carpenter 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
Firstly are we stating *the* CER or *a* CER? What happens when there is 
more than one CER? Does that then need an election process? And when the 
"winner" disappears because you've changed providers or router hardware 
or the router fails, all ULA's also get renumbered?
> unless all devices share a routing protocol, I have generally 
> preferred to generate unique ULAs per routing device.
>
Generating a ULA independently per router is potentially going to bring 
problems with the new RFC3484-revise as they'll almost certainly have 
different Global ID's (and thus a different /48 prefix), so ULA will not 
be preferred for communication between nodes connected to different routers.

Sometimes it's useful to take a complete opposite view to the way you've 
been thinking, and work though the consequences.

What about going to the extreme and giving up on central/coordinated 
control of a single ULA /48 Global ID throughout the Homenet?

What about tolerating static prefix assignments (for sensor networks)? 
We allow static individual IPv6 address assignments to end nodes as well 
as SLAAC, so why not tolerate statically assigned /64 prefixes? Even in 
Appletalk, the much vaunted champion of autoconfiguration, a network 
manager had to manually assign the network number range to at least one 
seed router in an extended network.

How about:

- multiple ULA /48 Global ID's within a single Homenet is not considered 
an "error"

    Every router may generate it's own ULA /48 Global ID independently, 
or use an existing one generated by another router.
    That gets rid of any time-ordering of installation, net splitting or 
net fusing issues.
    Also allows the electrician to set up his sensor network before the 
ISP arrives (or vice versa)

- routers should configure up one /64 prefix per interface for each ULA 
/48 Global ID present in the Homenet.

   This could use the same prefix assignment mechanism as PA addresses 
learned via DHCPv6 PD from the ISP.
   Each router could perhaps act as the seed router for its own ULA /48 
Global ID in the prefix assignment process.
   All of the ULA /48 Global ID's would be distributed throughout the 
complete Homenet network, so that if a router
   is added to the Homenet it may be an additional/new ULA /48 Global ID 
in the Homenet network,
   but the original ULA /64 prefixes derived from other routers' ULA /48 
Global ID's will still be available on all interfaces.
   That copes with mobile nodes and routers that are bought and sold. It 
also copes with failure of a single "master" router.

- every end node and router using RFC3484-revise should also configure 
up a ULA address for every ULA /64 prefix present.

   Dumb sensors may simply ignore 3484-revise (it's only informational) 
and always prefer ULA.
   End nodes using 3484-revise would now have a native ULA address from 
each ULA /48 Global ID,
   and therefore the proposed new rule in RFC3484-revise of source /48 
ULA = destination /48 ULA would
   come into play and ULA would always be preferred for local 
communications.

   You may end up with two or more usable ULA pairs between any two nodes,
   but is that a problem when we want high availability, and provider 
independence?

- prefix assignment autoconfiguration should avoid assigning prefixes 
that conflict with statically configured prefixes
   (e.g. hard coded sensor networks).

   That may require changing the tie-break mechanism in e.g. 
draft-baker-homenet-prefix-assignment-01
   so that a router with a static /64 prefix assignment can veto all 
other routers who (accidentally)
   try to auto-assign the same /64 and thus cause a collision.

   So it would be the equivalent of Duplicate Address Detection, but at 
the /64 prefix level.

OK each end node and router would have lots of prefixes and addresses 
(possibly two or more per router in the homenet) but isn't that less 
problematic than trying to centrally gather the ULA /48 Global ID's in 
use and then distribute an updated RFC3484-revise policy table to all 
end nodes, or magically electing a master node to coordinate the choice 
of a single ULA /48 Global ID?

regards,
RayH

---

From: Dave Taht <[email-masked]>
Date: Wed, 28 Mar 2012 01:25:27 -0700

On Wed, Mar 28, 2012 at 12:44 AM, Ray Hunter <[email-masked]> wrote:

> **
>>   Firstly are we stating *the* CER or *a* CER? What happens when there
> is more than one CER? Does that then need an election process? And when the
> "winner" disappears because you've changed providers or router hardware or
> the router fails, all ULA's also get renumbered?
>
> different Global ID's (and thus a different /48 prefix), so ULA will not be
> preferred for communication between nodes connected to different routers.
>
>
As I'm arguing with a draft that I haven't read, I'm a little at a loss.

Will certainly have different global ids.

ULA should be preferred for communication between nodes connected to
different routers if they are both in the ULA space. Consider linking two
offices via vpn, for example....

Other arguments are other autonomous devices (like devices that have
arbitrary numbers of subnets, like routers... your car...) or sensor
networks...

(01:09:33 AM) dtaht: There simply aren't enough routes in a homenet to fill
a routing table inside the home
(01:09:43 AM) dtaht: even if every router chooses a unique ULA

> control of a single ULA /48 Global ID throughout the Homenet?
Love it.

> What about tolerating static prefix assignments (for sensor networks)? We
> allow static individual IPv6 address assignments to end nodes as well as
> SLAAC, so why not tolerate statically assigned /64 prefixes? Even in
OK.

>    Every router may generate it's own ULA /48 Global ID independently, or
> use an existing one generated by another router.
>

Works for me.

>    Also allows the electrician to set up his sensor network before the ISP
> arrives (or vice versa)
>

SLAAC generally works fine.

>   is added to the Homenet it may be an additional/new ULA /48 Global ID in
> the Homenet network,
yes.

> - every end node and router using RFC3484-revise should also configure up
> a ULA address for every ULA /64 prefix present.
>
>
 is this the exact draft to which you are referring?

http://datatracker.ietf.org/doc/draft-ietf-6man-rfc3484-revise/

  Dumb sensors may simply ignore 3484-revise (it's only informational) and
> always prefer ULA.
>   and therefore the proposed new rule in RFC3484-revise of source /48 ULA
> = destination /48 ULA would
I think we are in disagreement here.

But I'm going to stop now, resume the conference, and play catchup on this
draft later.

> - prefix assignment autoconfiguration should avoid assigning prefixes that
> conflict with statically configured prefixes
>   so that a router with a static /64 prefix assignment can veto all other
> routers who (accidentally)
>   So it would be the equivalent of Duplicate Address Detection, but at the
> /64 prefix level.
>
>
> problematic than trying to centrally gather the ULA /48 Global ID's in use
> and then distribute an updated RFC3484-revise policy table to all end
> nodes, or magically electing a master node to coordinate the choice of a
> single ULA /48 Global ID?
>
>
> regards,
> RayH
>

---

From: Ray Hunter <[email-masked]>
Date: Wed, 28 Mar 2012 11:07:29 +0200

AFAIK  http://tools.ietf.org/html/draft-ietf-6man-rfc3484-revise-05 was 
the discussion to provide a delta update to 3484, so you'll find most of 
the background discussion there.

But the delta got so big that 
http://tools.ietf.org/html/draft-ietf-6man-rfc3484bis-01 attempts to 
merge these changes back into 3484 to create one complete doc that 
replaces the original 3484.

Dave Taht wrote:
> <http://www.bufferbloat.net>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 29 Mar 2012 08:44:25 +1300

> address types are available to a given host ?

The second. If the only choice is ULA<->global, of course you try it,
but then happy-eyeballs may kick in.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Thu, 29 Mar 2012 10:19:10 +0200

>>>>> "Ray" == Ray Hunter <[email-masked]> writes:
    Ray> Generating a ULA independently per router is potentially going
    Ray> to bring problems with the new RFC3484-revise as they'll almost
    Ray> certainly have different Global ID's (and thus a different /48
    Ray> prefix), so ULA will not be preferred for communication between
    Ray> nodes connected to different routers.

    Ray> Sometimes it's useful to take a complete opposite view to the
    Ray> way you've been thinking, and work though the consequences.

Perhaps rfc3484bis needs to say that any ULA is good to speak to any
other ULA, regardless of longest prefix match.  

This puts a constraint on homenet topology that all ULAs have to be
reachable from all other ULAs.  Perhaps that is in the end, acceptable.

    Ray> What about going to the extreme and giving up on
    Ray> central/coordinated control of a single ULA /48 Global ID
    Ray> throughout the Homenet?

    Ray> What about tolerating static prefix assignments (for sensor
    Ray> networks)? We allow static individual IPv6 address assignments
    Ray> to end nodes as well as SLAAC, so why not tolerate statically

    Ray> assigned /64 prefixes? Even in Appletalk, the much vaunted
    Ray> champion of autoconfiguration, a network manager had to
    Ray> manually assign the network number range to at least one seed
    Ray> router in an extended network.

    Ray> - multiple ULA /48 Global ID's within a single Homenet is not
    Ray> considered an "error"

Yes.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: David R Oran <[email-masked]>
Date: Thu, 29 Mar 2012 12:17:02 +0200

> http://thingsonip.blogspot.fr/2012/03/smart-igloos.html
I assume you need special protocols to get through - does that mean we need to add ICE to the homenet suite?

:-)