Subject: Re: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.txt]

From: Kerry Lynn <[email-masked]>
Date: Sat, 17 Mar 2012 13:02:06 -0400

On Sat, Mar 17, 2012 at 2:22 AM, Dave Thaler <[email-masked]> wrote:
> Brian Carpenter writes:
> [...]
>> Let me be clear. If a local service has (for some reason) both a ULA and a non-
>> ULA global address, and the host has both, I think the correct default
>> behaviour is for the ULA address pair to be used.
>
> As I put into the doc, I don't think that's quite right.
>
> If both the source and dest ULAs are in the same /48 then I think the correct
> default is as you say (use ULA).
>
> If the source and dest ULAs are in different /48's then I think the correct
> default is instead to use the non-ULA global, since there's no guarantee of
> routability between different /48s.  So unless configured otherwise, one
> has to assume it's far more problematic than a non-ULA global.
>
Do you mean "no guarantee of symmetric routability"?  The fact that the
packet arrived in the first place seems to indicate earlier policy choices
(e.g. the sender may not have a non-ULA global address, and the two /48s
already seem to share a common definition of "site").

I am still relatively new to homenet and I am surely missing a lot of
background.  Has anyone discussed dealing with multiple /48 ULA
prefixes in a single site?

Thanks, -K-

> You'll find the above logic in the current 3484bis draft.
>
> -Dave
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Anders Brandt <[email-masked]>
Date: Tue, 20 Mar 2012 08:51:31 +0000

Kerry Lynn writes:

> >> Let me be clear. If a local service has (for some reason) both a ULA
> >> and a non- ULA global address, and the host has both, I think the
> >> correct default behaviour is for the ULA address pair to be used.
> >
> > If both the source and dest ULAs are in the same /48 then I think the
> > correct default is as you say (use ULA).
> >
> > If the source and dest ULAs are in different /48's then I think the
> > correct default is instead to use the non-ULA global, since there's no
> > guarantee of routability between different /48s.  So unless configured
> > otherwise, one has to assume it's far more problematic than a non-ULA
> global.
> >
> packet arrived in the first place seems to indicate earlier policy choices (e.g.
> the sender may not have a non-ULA global address, and the two /48s already
> seem to share a common definition of "site").
> 
> background.  Has anyone discussed dealing with multiple /48 ULA prefixes
> in a single site?

I would like to second Kerry.

It is a surprise to me that ULA addresses are not by default routable within the site.
I can easily imagine a number of LLN border routers which autonomously allocate
different ULA prefixes for use within their individual LLN subnets.

Meeting a ULA address outside the local prefix will cause the LLN node to forward
its IP packets to the default gateway (border router) of the LLN subnet. This way
packets can travel between LLN subnets using normal routing with long-term stable
ULA addresses. We need the stable addresses for control-style applications in LLNs.

Obviously it requires a routing protocol in the (homenet) LAN but are there other issues?

Thanks,
  Anders
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Mar 2012 10:25:57 +1300

> different ULA prefixes for use within their individual LLN subnets.

IMHO that should be a NOT RECOMMENDED behaviour. ULAs make sense if they
cover an entire enterprise or home network, but not if they cover a subset.

> Obviously it requires a routing protocol in the (homenet) LAN but are there other issues?

It doesn't just require a routing protocol; it also requires a routing policy
that knows which routers have to block the ULAs (plural). That seems a lot
more complex that a rule that says only a border router originates and delegates
a ULA prefix, because that border router would also know to block the
prefix across the border.

Anyway - maybe you should look at draft-liu-v6ops-ula-usage-analysis
and discuss it over on v6ops.

    Brian

---

From: Tim Chown <[email-masked]>
Date: Wed, 21 Mar 2012 11:55:05 +0000

> prefix across the border.

So we need to determine what the homenet arch text will say on this. 

I think the assumption so far has been that, as per PD8 in draft-ietf-homenet-arch-02, 
one router would be elected the "master" to delegate /64 ULA prefixes within the
homenet, both to ULA-only LLNs and to links that also have a GUA prefix.  If there's 
an assumption an LLN router will not support that, and instead generate its own /48 
ULA, we need to talk about that, or any other scenario that will lead to multiple /48 ULAs 
in a single homenet site.

The arch text currently says that ULAs should be used (CN1) and that ULAs should be 
preferred for internal communications to GUAs (section 2.4).  It doesn't say how connections 
from outside the homenet can be made to internal ULA-only devices.

The 3484-bis text has changed the default ULA preference to protect against ULA leakage,
so if you now want ULAs preferred you need to somehow inject the specific site /48 ULA
being used with high precedence into the policy table (and as also pointed out here if your 
site is using less than a /48, you should also have some way to learn what the site prefix 
length is). In the homenet case is that injection achieved on receipt of an RA, or would it 
require the proposed DHCPv6 option to be used (which may not be widely implemented 
for some time, and the DHCPv6 server still needs to learn the ULA to put in the option)? 

On the one hand homenet is saying "we'd prefer to use ULAs by default without needing
some magic to achieve it" while 6man is saying "we need to protect against ULA leakage, 
so if you want to prefer ULA for internal connection stability figure out the magic".  

This needs to be mapped to words for the homenet arch text.

Tim

---

From: Anders Brandt <[email-masked]>
Date: Wed, 21 Mar 2012 12:13:19 +0000

Brian Carpenter writes:
> > I can easily imagine a number of LLN border routers which autonomously
> > allocate different ULA prefixes for use within their individual LLN subnets.
> 
> IMHO that should be a NOT RECOMMENDED behaviour. ULAs make sense if
> they cover an entire enterprise or home network, but not if they cover a
> subset.

I would like to see some arguments for that opinion?

To me subnet ULAs make a lot sense to me in environments where
100% autoconfiguration is required while remaining robust towards
changing ISP prefixes and backbone topologies.

The basic premise for the average homenet user is that he/she has
absolutely no clue what goes on in the network. And should not have.
 
> > Meeting a ULA address outside the local prefix will cause the LLN node
> > to forward its IP packets to the default gateway (border router) of
> > the LLN subnet. This way packets can travel between LLN subnets using
> > normal routing with long-term stable ULA addresses. We need the stable
> addresses for control-style applications in LLNs.
> >
> more complex that a rule that says only a border router originates and
> delegates a ULA prefix, because that border router would also know to block
> the prefix across the border.

This "master" router may be added to the homenet at a later stage - e.g. when
changing ISP. My lightswitch-to-lamp address associations between two subnets
have to survive such changes.
I cannot rely on any prefix delegated from an unreliable source such as an ISP router.

I cannot rely on my user hand-carrying a ULA prefix delegated by the old ISP
router into the new ISP router. This ISP router may even be blocked for user
manipulation. And again, my user has no qualifications for doing this.

My understanding of the homenet CER is that it by default will filter any
ULA addressed traffic (?). Thus, no ULAs leave or enter into the Internet.

> and discuss it over on v6ops.

I am familiar with Bing Liu's draft. Actually I see no objections against
multiple ULA prefixes in homenets in this draft.
Contrary, the draft says 

<quote>hosts assigned with ULA may occasionally be merged into one
  network</quote>....
<quote>make merging of networks simple and
  without the need to renumbering overlapping IP address space. </quote>

I agree in this text.

I agree that the discussion is also interesting to v6ops but I would like to
converge on the applicability within homenets before "taking it to the next level".

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

---

From: Anders Brandt <[email-masked]>
Date: Wed, 21 Mar 2012 12:18:36 +0000

Tim Chown wrote:
>Wednesday, March 21, 2012 12:55
> >> I can easily imagine a number of LLN border routers which
> >> autonomously allocate different ULA prefixes for use within their
> individual LLN subnets.
> >
> >> Meeting a ULA address outside the local prefix will cause the LLN
> >> node to forward its IP packets to the default gateway (border router)
> >> of the LLN subnet. This way packets can travel between LLN subnets
> >> using normal routing with long-term stable ULA addresses. We need the
> stable addresses for control-style applications in LLNs.
> >>
> > It doesn't just require a routing protocol; it also requires a routing
> > policy that knows which routers have to block the ULAs (plural). That
> > seems a lot more complex that a rule that says only a border router
> > originates and delegates a ULA prefix, because that border router
> > would also know to block the prefix across the border.
> 
> I think the assumption so far has been that, as per PD8 in draft-ietf-
> homenet-arch-02, one router would be elected the "master" to delegate /64
> ULA prefixes within the homenet, both to ULA-only LLNs and to links that
> also have a GUA prefix.  If there's an assumption an LLN router will not
> support that, and instead generate its own /48 ULA, we need to talk about
> that, or any other scenario that will lead to multiple /48 ULAs in a single
> homenet site.
> 
> The arch text currently says that ULAs should be used (CN1) and that ULAs
> should be preferred for internal communications to GUAs (section 2.4).  It
> doesn't say how connections from outside the homenet can be made to
> internal ULA-only devices.

Is it obvious that you want to do that?
I thought the entire ULA discussion was homenet internal only?

Access from the outside will require tunneling or an additional global
address, I guess?

- Anders

> The 3484-bis text has changed the default ULA preference to protect against
> ULA leakage, so if you now want ULAs preferred you need to somehow
> inject the specific site /48 ULA being used with high precedence into the
> policy table (and as also pointed out here if your site is using less than a /48,
> you should also have some way to learn what the site prefix length is). In
> the homenet case is that injection achieved on receipt of an RA, or would it
> require the proposed DHCPv6 option to be used (which may not be widely
> implemented for some time, and the DHCPv6 server still needs to learn the
> ULA to put in the option)?
> 
> On the one hand homenet is saying "we'd prefer to use ULAs by default
> without needing some magic to achieve it" while 6man is saying "we need
> to protect against ULA leakage, so if you want to prefer ULA for internal
> connection stability figure out the magic".
> 
> >>>> -------------------------------------------------------------------
> >>>> - IETF IPv6 working group mailing list [email-masked] Administrative

---

From: Don Sturek <[email-masked]>
Date: Wed, 21 Mar 2012 05:24:55 -0700

Hi Tim,

One more consideration:
In the home, it is possible that multiple independent subnets could be
combined, each with their own ULA prefix.  This would happen in cases
where the homeowner buys multiple silo'ed solutions (like a home
automation system, Wi-Fi AP with connected MACs/Pcs, etc) then purchases a
cross connect device that integrates these solutions.

Don

On 3/21/12 4:55 AM, "Tim Chown" <[email-masked]> wrote:

>>>allocate
>>>to forward
>>policy
>>delegates
>should be 
>implemented 
>without needing

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Mar 2012 08:35:27 +1300

Don,

> cross connect device that integrates these solutions.

Yes, anything could happen and probably will. So while a single ULA per
site is the simple and obvious case (and I don't have any argument for
Anders except KISS), there *will* be cases where several ULAs pop
up, and I think resolving routing issues in that situation is likely
to be troublesome. We can't resolve it as we do for enterprise networks
by saying that the network's manager will manually configure appropriate
routes.

    Brian

---

From: Ray Hunter <[email-masked]>
Date: Thu, 22 Mar 2012 09:29:15 +0100

+1

Firstly, I have been lurking on the 3484-revise discussion in 6man for a 
long time. I agree with Brian's proposal:
[source & destination of a /48 ULA prefix match => prefer over 2000:/3 
space. Otherwise don't (by default).]

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

One reason ULA seems to be mentioned is "time-invariance of addressing 
for use by sensor networks." 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.

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

So I humbly suggest the WG should first concentrate on properly 
formulating and clarifying the high level architectural requirements, 
rather than on ULA in and of itself.

regards,
RayH

Brian E Carpenter wrote:
>> On 3/21/12 4:55 AM, "Tim Chown"<[email-masked]>  wrote:
>>
>>

---

From: Anders Brandt <[email-masked]>
Date: Thu, 22 Mar 2012 09:06:22 +0000

Ray,

> So I humbly suggest the WG should first concentrate on properly formulating and clarifying the high level architectural requirements,

I agree that we must concentrate on the architecture requirements first.
It would however be unfortunate if these requirements ruled out the case of routing between homenet subnets based on stable addresses when
we have a couple of use cases for LLNs that call such functionality.
Maybe I should provide some use cases to Bing's draft to outline why this matters to us LLN guys.

I think I need some education on ULA routing - starting new thread...

- Anders

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ray Hunter
Sent: Thursday, March 22, 2012 09:29
To: Brian E Carpenter
Cc: 6man; Tim Chown; Don Sturek; [email-masked] Group
Subject: Re: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.txt]

+1

Firstly, I have been lurking on the 3484-revise discussion in 6man for a long time. I agree with Brian's proposal:
[source & destination of a /48 ULA prefix match => prefer over 2000:/3 space. Otherwise don't (by default).]

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

One reason ULA seems to be mentioned is "time-invariance of addressing for use by sensor networks." 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.

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

So I humbly suggest the WG should first concentrate on properly formulating and clarifying the high level architectural requirements, rather than on ULA in and of itself.

regards,
RayH

Brian E Carpenter wrote:

Don,

Hi Tim,

One more consideration:

routes.

    Brian

Don

On 3/21/12 4:55 AM, "Tim Chown" <[email-masked]><mailto:[email-masked]> wrote:

It is a surprise to me that ULA addresses are not by default routable

within the site.

allocate

cover an entire enterprise or home network, but not if they cover a

subset.

to forward

its IP packets to the default gateway (border router) of the LLN

subnet. This way

packets can travel between LLN subnets using normal routing with

long-term stable

ULA addresses. We need the stable addresses for control-style

applications in LLNs.

Obviously it requires a routing protocol in the (homenet) LAN but are

there other issues?

policy

that knows which routers have to block the ULAs (plural). That seems a

lot

delegates

I think the assumption so far has been that, as per PD8 in

draft-ietf-homenet-arch-02,

one router would be elected the "master" to delegate /64 ULA prefixes

within the

homenet, both to ULA-only LLNs and to links that also have a GUA prefix.

If there's

an assumption an LLN router will not support that, and instead generate

its own /48

ULA, we need to talk about that, or any other scenario that will lead to

multiple /48 ULAs

should be

preferred for internal communications to GUAs (section 2.4).  It doesn't

say how connections

>from outside the homenet can be made to internal ULA-only devices.

The 3484-bis text has changed the default ULA preference to protect

against ULA leakage,

so if you now want ULAs preferred you need to somehow inject the specific

site /48 ULA

being used with high precedence into the policy table (and as also

pointed out here if your

site is using less than a /48, you should also have some way to learn

what the site prefix

length is). In the homenet case is that injection achieved on receipt of

an RA, or would it

implemented

for some time, and the DHCPv6 server still needs to learn the ULA to put

in the option)?

without needing

some magic to achieve it" while 6man is saying "we need to protect

against ULA leakage,

so if you want to prefer ULA for internal connection stability figure out

the magic".

Tim

   Brian

Thanks,

 Anders

-Dave

[email-masked]<mailto:[email-masked]>

homenet mailing list

[email-masked]<mailto:[email-masked]>

homenet mailing list

[email-masked]<mailto:[email-masked]>

[email-masked]<mailto:[email-masked]>

[email-masked]<mailto:[email-masked]>

[email-masked]<mailto:[email-masked]>