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

From: Arifumi Matsumoto <[email-masked]>
Date: Fri, 16 Mar 2012 19:30:07 +0900

Dave,

On 2012/03/01, at 11:20, Dave Thaler wrote:

>> -----Original Message-----
>> From: Arifumi Matsumoto [mailto:[email-masked]]
>> Sent: Thursday, February 23, 2012 10:14 PM
>> To: Brian E Carpenter
>> Cc: Dave Thaler; Chris Grundemann; [email-masked]; Brian Haberman; Bob
>> Hinden
>> Subject: Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt]
>> 
>> Dave,
>> 
>> in Example section of draft-ietf-6man-rfc3484bis-00.txt, I found the response to
>> this issue of ULA scope.
>> 
>> 10.6.  Configuring ULA Preference
>> ...
>>   Since ULAs are defined to have a /48 site prefix, an implementation
>>   might choose to add such a row automatically on a machine with a ULA.
>> 
>>   It is also worth noting that ULAs are assigned global scope.  As
>>   such, the existence of one or more rows in the prefix policy table is
>>   important so that source address selection does not choose a ULA
>>   purely based on longest match:
>> 
>>   Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1
>>   Destination Address List: ff00:1
>>   Result: 2001:db8:1::1 (prefer matching label)
>> 
>> 
>> IMO, this implicit specification causes several problems.
>> 
>> First of all, if you leave it to implementation, this creates an interoperability
>> problem. In the sense that a site administrator, an application developer, a
>> network designer, have to take care of the nodes with different address
>> selection behavior.
> 
> Are you arguing it should be mandatory, not optional?  (I'm guessing so based
> on the previous discussion of "macros" in the table.)
> 
> But still, you have to take care of nodes with different address selection behavior
> anyway if you allow heterogeneous hosts, since you'll have
> a) hosts that don't do RFC 3484
> b) hosts that do RFC 3484
> c) hosts that do 3484bis
> 
> And even within a category above, the IPv4 source address selection behavior
> will vary since that's not specified.
> 
> At best you can argue to minimize the problem as much as possible, but
> you can't make it go away.

Rather, my question was about the design choice.

Regarding the design of ULA and how to use the ULA, can we agree that 
ULA-to-ULA communication within the same /48 prefix is not always preferred
over other communications using IPv4 or IPv6 global addresses ?

>> Second,
>> when a user configures his policy table, the configured table is overwritten by
>> this implementation dependent policy injection behavior ?
>> Can the user suppress this behavior of policy injection ?
>> This issue should arise also when a policy distributing mechanism is ready.
> 
> Good questions.  Do you have suggested answers to those questions?
> I might throw out a strawman of:
> 
> Any automatic rows added by the implementation as a result of address
> acquisition MUST NOT override a row for the same prefix configured
> via other means.   That is, rows can be added but never updated
> automatically.   An implementation SHOULD provide a means for
> an administrator to disable automatic row additions.

My suggested answer for this was to use macros, which can be
added/deleted by a user, and interpreted as the actual prefix
attached to the hosts.

Best regards,

--
Arifumi Matsumoto
  NGN System Architecture Project
  NTT Service Integration Laboratories
  E-mail: [email-masked]
  TEL +81-422-59-3334 FAX +81-422-59-6364

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 17 Mar 2012 07:41:50 +1300

On 2012-03-16 23:30, Arifumi Matsumoto wrote:
...
> over other communications using IPv4 or IPv6 global addresses ?

I would expect it to be preferred as a result of longest match; I would
not expect it to be a special case in the default policy for global
scope addresses, if that is the question.

> added/deleted by a user, and interpreted as the actual prefix

That's an implementation method. I think Dave's proposed rule is
correct.

    Brian

---

From: Mark Andrews <[email-masked]>
Date: Sat, 17 Mar 2012 11:12:52 +1100

> That's an implementation method. I think Dave's proposed rule is

What I see missing is a way for a node to know what the site boundaries
are with respect to address selection.   Adding a site prefix length
to RA Prefix Information would provide a 99.99% solution to this.  If
the Site Prefix field is non-zero it is valid.

e.g.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     | Prefix Length |L|A| Reserved1 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Valid Lifetime                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Preferred Lifetime                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Site Prefix  |           Reserved2                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                            Prefix                             +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

---

From: Dave Thaler <[email-masked]>
Date: Sat, 17 Mar 2012 00:25:22 +0000

See
http://tools.ietf.org/html/draft-ietf-ipngwg-site-prefixes-05

-Dave

> From: Mark Andrews [mailto:[email-masked]]
> Sent: Friday, March 16, 2012 5:13 PM
> To: Brian E Carpenter
> Cc: Arifumi Matsumoto; Bob Hinden; [email-masked]; Brian Haberman; Dave
> Thaler
> > > Regarding the design of ULA and how to use the ULA, can we agree
> > > that ULA-to-ULA communication within the same /48 prefix is not
> > > always preferred over other communications using IPv4 or IPv6 global
> addresses ?
> >
> > I would expect it to be preferred as a result of longest match; I
> > would not expect it to be a special case in the default policy for
> > global scope addresses, if that is the question.
> >
> > >>> Second,
> > >>> when a user configures his policy table, the configured table is
> > >>> overwrit
> > ten by
> > >>> This issue should arise also when a policy distributing mechanism
> > >>> is read
> > y.
> > >> Any automatic rows added by the implementation as a result of
> > >> address acquisition MUST NOT override a row for the same prefix
> configured
> to RA Prefix Information would provide a 99.99% solution to this.  If the Site
> Prefix field is non-zero it is valid.
> 
> e.g.
> 
>        0                   1                   2                   3

---

From: Arifumi Matsumoto <[email-masked]>
Date: Sat, 17 Mar 2012 09:29:37 +0900

Brian,

> scope addresses, if that is the question.

ULA-to-ULA will not be preferred, because ULAs are assigned lower
precedence value in the policy table than those of IPv4 and IPv6
global addresses.

Best,

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

---

From: Mark Andrews <[email-masked]>
Date: Sat, 17 Mar 2012 11:52:26 +1100

In message <[email-masked]
> http://tools.ietf.org/html/draft-ietf-ipngwg-site-prefixes-05

Essentially the same thing with a wasted bit.   No site is "the
world" so you don't need the S bit if you make valid site prefix
lengths 1..128.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 16 Mar 2012 20:37:08 -0500

Arifumi,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Arifumi Matsumoto
Sent: Friday, March 16, 2012 8:30 PM
To: Brian E Carpenter
Cc: [email-masked]; Brian Haberman; Bob Hinden; Dave Thaler
Subject: Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt]

>global addresses.

I certainly understand if a host has an IPv4 and a ULA assigned, the
policy table prefers the IPv4 over the ULA otherwise Internet
connectivity for the host breaks down.  Likewise if the host has an IPv6
global and a ULA (which is also globally scoped), the IPv6 global is
preferred or Internet connectivity breaks down.   However, the issue
that Brian raised needs some thought.  The host has an IPv4, IPv6
global, and a ULA address. What if the packet destination is a ULA for
local communication, so why not use a longest-prefix match and use a ULA
source?  How does a longest-prefix match relate to the policy table?  Do
we have a mode where the policy table is the only entity used for source
address selection (SAS)? If yes, then how does the ULA to ULA
communication above work?

Best back,

Hemant

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 17 Mar 2012 16:18:03 +1300

> communication above work?

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.
This is a matter of address-pair selection, however, not of
source or destination selection alone.

   Brian

---

From: Dave Thaler <[email-masked]>
Date: Sat, 17 Mar 2012 06:22:36 +0000

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.

You'll find the above logic in the current 3484bis draft.

-Dave

---

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

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

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 18 Mar 2012 08:03:56 +1300

> has to assume it's far more problematic than a non-ULA global.

Yes, I agree, that is a case that would need to be handled by locally
installed rules if it was required to work (e.g. after a merger of
two intranets using different ULA prefixes). I doubt that default rules
can cover it.

    Brian

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 19 Mar 2012 13:08:27 +0900

Dave,

> default is as you say (use ULA).

What I see a possible problem is that, in the current bis-01, this is not
implemented as a required behavior.

That is, the logic to prefer ULA in the same /48 is in the Example section,
and is not explicitly preferred/required/mandated in the document.

> has to assume it's far more problematic than a non-ULA global.

I do not see any problem about this point.

Best regards,

---

From: "Marc Lampo" <[email-masked]>
Date: Mon, 19 Mar 2012 08:34:09 +0100 (CET)

Hello,

+1 for Brian's statement : ULA within same /48, prefer ULA.

For ULA not within same /48 :
Please do not forget VPN !
In the IPv4 world, numerous devices, with private address space,
Communicate through site-to-site VPN's.
I'd assume this is equivalent to "ULA not in same /48".
How could an end-device decide whether or not VPN is in place ?

Wouldn't it be preferable to let "name resolving" decide which address
to return to a client ?
And if name resolving returns ULA, let end-device use ULA as well.
(If there is no VPN in place, it would be a configuration error
 in the name resolving infrastructure)
That way, network admins decide centrally, trough name resolving,
how some party is can be reached.

Any errors there would be name resolving which can, through DNS,
 be centrally solved.
As opposed to some "smart" algorithm on end nodes that mistakingly
 choses the wrong address (and requiring some update on all of them ...)

Kind regards,

Marc Lampo

-----Original Message-----
From: Dave Thaler [mailto:[email-masked]]
Sent: 17 March 2012 07:23 AM
To: Brian E Carpenter; Hemant Singh (shemant)
Cc: [email-masked]; Brian Haberman; Arifumi Matsumoto; Bob Hinden
Subject: RE: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt]

Brian Carpenter writes:
[...]
> and a non- ULA global address, and the host has both, I think the

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.

-Dave

---

From: Mark Andrews <[email-masked]>
Date: Tue, 20 Mar 2012 01:14:02 +1100

In message <00f801cd05a2$abfce190$03f6a4b0$@[email-masked]>, "Marc Lampo" write
>  choses the wrong address (and requiring some update on all of them ...)

Are connecting a node or a net over the VPN?

For a node this is a non-issue as the VPN's interface will be in
one ULA and home net in the other ULA.  The node is a site boundary.

If you are connecting a net then you can do PD request(s) and
advertise the returned prefixes.  If the upstream starts to run out
of prefixes they just generate a additional ULA prefix and number
all the servers from it.  Different VPN use different ULA but all
can reach the central servers.  By the time a organisation reaches
this level of complexity they are a small ISP in their own right
and should be able to get /32.

Mark

---

From: "Marc Lampo" <[email-masked]>
Date: Mon, 19 Mar 2012 15:25:26 +0100 (CET)

Allow me to clarify with an example.

In my IP(v4) experience, I have a customer with offices over multiple
Continents - private address space in use everywhere -
site-to-site VPN's (== connecting networks) connect the offices.

If I map to IPv6 this might be one /48 ULA range;
Some networks in central HQ, others remotely, behind site-to-site VPN.

--> if one end-node in one network wants to reach another,
     in another network, its traffic must travel through the VPN.

Please observe that using public addresses (not using ULA)
might do away with address selection "challenges"
but would imply that networks on all continents will have to be
renumbered if the central HQ changes ISP (and hence : public IPv6
addresses).
Something I'd like to avoid ...

Kind regards,

Marc Lampo

-----Original Message-----
From: Mark Andrews [mailto:[email-masked]] 
Sent: 19 March 2012 03:14 PM
To: Marc Lampo
Cc: 'Dave Thaler'; 'Brian E Carpenter'; 'Hemant Singh (shemant)'; 'Arifumi
Matsumoto'; 'Brian Haberman'; [email-masked]; 'Bob Hinden'
Subject: Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt]

In message <00f801cd05a2$abfce190$03f6a4b0$@[email-masked]>, "Marc Lampo"
write
s:
> (If there is no VPN in place, it would be a configuration error  in 
> the name resolving infrastructure) That way, network admins decide 
> centrally, trough name resolving, how some party is can be reached.
> 
> Any errors there would be name resolving which can, through DNS,  be 
> centrally solved.

For a node this is a non-issue as the VPN's interface will be in one ULA
and home net in the other ULA.  The node is a site boundary.

If you are connecting a net then you can do PD request(s) and advertise
the returned prefixes.  If the upstream starts to run out of prefixes they
just generate a additional ULA prefix and number all the servers from it.
Different VPN use different ULA but all can reach the central servers.  By
the time a organisation reaches this level of complexity they are a small
ISP in their own right and should be able to get /32.

Mark

---

From: Mark Andrews <[email-masked]>
Date: Tue, 20 Mar 2012 09:08:01 +1100

In message <01f401cd05dc$20914df0$61b3e9d0$@[email-masked]>, "Marc Lampo" write
> Something I'd like to avoid ...

Well with a single ULA you have 65536 /64 sized networks to use
where ever you want.  You have ULA:0000/56 in Paris, ULA:0100/55
in New York.  You don't have to keep things bit aligned but it
helps.  65536 prefixes isn't a lot of routing information.  Think
of it in IPv4 terms as 10/8 and you are handing out /24 for each
subnet except you know you won't need more than /24 ever.

Mark

---

From: Mark Andrews <[email-masked]>
Date: Tue, 20 Mar 2012 09:29:06 +1100

> subnet except you know you won't need more than /24 ever.

Alternatively you can give each site its own ULA and you use non
default address selection rules.  Remember we are talking about the
default rules here.  There are billions of more homes than there
are businesses.

They would use rules like the follow which give all the sites a
common label:

	::1      50   0
	ULA1:/48 45 100
	ULA2:/48 45 100
	ULA3:/48 45 100
	::/0     40   1
	2002::	 30   2
	fc00::	 0    3
 
Whereas the default rules generate a table like if it was multi-homed
to three sites:

	::1      50   0
	ULA1:/48 45   4
	ULA2:/48 45   5
	ULA3:/48 45   6
	::/0     40   1
	2002::	 30   2
	fc00::	 0    3

---

From: "Marc Lampo" <[email-masked]>
Date: Tue, 20 Mar 2012 08:10:31 +0100 (CET)

Hello,

I understand what you are writing, but is this the right way ?

The address selection table is, as far as I understand,
statically defined - not dynamically configurable (SLAAC or DHCPv6).
So, the suggestion is to adapt the table on every node of
the organisation.
In other words, every node in the organisation is somehow
 - via the address selection table - aware of the organisations
 network topology (VPN's and so).
Is this desired ?

Kind regards,

Marc Lampo

-----Original Message-----
From: Mark Andrews [mailto:[email-masked]] 
Sent: 19 March 2012 11:29 PM
Cc: Marc Lampo; 'Bob Hinden'; 'Brian Haberman'; [email-masked]; 'Arifumi
Matsumoto'; 'Dave Thaler'
Subject: Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt]

In message <[email-masked]>, Mark Andrews
writes:
> 
> In message <01f401cd05dc$20914df0$61b3e9d0$@[email-masked]>, "Marc 
> Lampo" wri te
> s:
> > In my IP(v4) experience, I have a customer with offices over 
> > multiple Continents - private address space in use everywhere - 
> > If I map to IPv6 this might be one /48 ULA range; Some networks in 
> > central HQ, others remotely, behind site-to-site VPN.
> > 
> > Please observe that using public addresses (not using ULA) might do 
> > away with address selection "challenges"
> Well with a single ULA you have 65536 /64 sized networks to use where 
> ever you want.  You have ULA:0000/56 in Paris, ULA:0100/55 in New 
> York.  You don't have to keep things bit aligned but it helps.  65536 
> prefixes isn't a lot of routing information.  Think of it in IPv4 
> terms as 10/8 and you are handing out /24 for each subnet except you 
> know you won't need more than /24 ever.

Alternatively you can give each site its own ULA and you use non default
address selection rules.  Remember we are talking about the default rules
here.  There are billions of more homes than there are businesses.

They would use rules like the follow which give all the sites a common
label:

	::1      50   0
	ULA1:/48 45 100
	ULA2:/48 45 100
	ULA3:/48 45 100
	::/0     40   1
	2002::	 30   2
	fc00::	 0    3
 
Whereas the default rules generate a table like if it was multi-homed to
three sites:

	::1      50   0
	ULA1:/48 45   4
	ULA2:/48 45   5
	ULA3:/48 45   6
	::/0     40   1
	2002::	 30   2
	fc00::	 0    3

---

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

Kerry Lynn writes:

> > 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: Mark Andrews <[email-masked]>
Date: Tue, 20 Mar 2012 22:04:15 +1100

In message <006e01cd0668$898f0770$9cad1650$@[email-masked]>, "Marc Lampo" write
> I understand what you are writing, but is this the right way ?
 
Yes.  It was always intended that this be updatable network wide.

http://tools.ietf.org/html/draft-fujisaki-dhc-addr-select-opt-09

> So, the suggestion is to adapt the table on every node of

Yep.  DHCP does this sort of thing very well.

> network topology (VPN's and so).

Sure, why not?  Lots of equipment won't need to know it but they are
all capable of processing.

---

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: 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

---

From: "t.petch" <[email-masked]>
Date: Wed, 21 Mar 2012 12:35:57 +0100

----- Original Message -----
From: "Mark Andrews" <[email-masked]>
To: "Marc Lampo" <[email-masked]>
Cc: <[email-masked]>; "'Brian Haberman'" <[email-masked]>; "'Bob
Hinden'" <[email-masked]>; "'Arifumi Matsumoto'" <[email-masked]>; "'Dave
Thaler'" <[email-masked]>
Sent: Tuesday, March 20, 2012 12:04 PM
>
> In message <006e01cd0668$898f0770$9cad1650$@[email-masked]>, "Marc Lampo"
> Yep.  DHCP does this sort of thing very well.

I note that the I-D referenced above allocates 32 bit for the zone index which
will suit a few implementations and not suit many, unless the intention is to
use
the SNMP ifIndex and map from that to the string used by such implementations.

Hopefully, 6man will be invited to review this as and when it progresses,
otherwise it will have to be at IETF Last Call:-(

Tom Petch
<snip>

---

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: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Mar 2012 08:28:50 +1300

> the SNMP ifIndex and map from that to the string used by such implementations.

Of course that is how it works. The socket API uses a uint32_t for
the zone index; only the user interface uses a string. It seems appropriate
to use the uint32_t also in the MIB and the DHCP option.

We already covered this on another thread:
http://www.ietf.org/mail-archive/web/ipv6/current/msg15424.html

I agree this should be made very clear in the text.

   Brian

---

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

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

---

From: Arifumi Matsumoto <[email-masked]>
Date: Thu, 22 Mar 2012 17:22:45 +0900

Hi,

> I agree this should be made very clear in the text.

Brian, thank you for answering this question.

BTW, this draft was now adopted as 6man wg item, and WGLCed by dhcwg.
The WGLC in 6man about this draft should happen soon after 3484bis
discussion is settled.

http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-03

Thanks,

---

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]>