Subject: [v6ops] new draft: draft-ietf-v6ops-ula-usage-recommendations

From: <[email-masked]>
Date: Sat, 18 May 2013 05:45:00 -0700 (PDT)

A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations. Please take a look at it and comment.

---

From: "Liubing (Leo)" <[email-masked]>
Date: Mon, 20 May 2013 03:54:06 +0000

Hi, Dear all

This new ietf-00 draft is based on http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis-05
And the document title was changed according to the discussion and the chair's advice. 

During the last IETF meeting, we had a significant amount of discussion on this draft. And lots of comments were received in the meeting and mail discussion. Thanks for all your contributions.

However, we couldn't include all your suggestions in the new ietf-00 version. Since the adoption call was based on the old -05 I-D, and we still have much controversy on some aspects. So the ietf-00 only did some minor revisions and added a bit general consensus discussion (see section 4).

But I summarized several important topics that might be worth to be included in the future:
1. add some pros/cons of each general use cases
2. add some operational considerations, might include, but not limited to the following:
 2.1 ULA+IPv4 case, might reduce the user experience, as described in RFC5220, section 2.2.2 
 2.2 ULA with a default route in host might be problematic, we need to deal with the ULA preference properly
 2.3 ULA+NPTv6, need some specific considerations, since NPTv6 is a stateless one-to-one mapping

Any comments to the new ietf-00 draft and the above potential revisions are welcomed.

Many thanks!

B.R.
Bing 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of [email-masked]
> Sent: Saturday, May 18, 2013 8:45 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [v6ops] new draft: draft-ietf-v6ops-ula-usage-recommendations
> 
> 
> A new draft has been posted, at
> http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations.
> Please take a look at it and comment.
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 20 May 2013 16:49:43 +0900

Bing,

a few comments:

I. "Notice that, as described in [RFC4864], in practice, applications may
treat ULAs like global-scope addresses, but address selection algorithms
may need to distinguish between ULAs and ordinary GUA Global-scope Unicast
Address) to ensure bidirectional communications."

1. "In practice, applications may treat ULAs like global-scope addresses"
is incorrect. ULAs are global-scope addresses, and we should state that
they are.
2.  "Address selection algorithms may need to distinguish between ULAs and
ordinary GUA (Global-scope Unicast Address) to ensure bidirectional
communications." Which algorithms? Do the ones in RFC 6724 do this? If so,
we should simply say that "applications distinguish between ULAs and GUA
(Global-scope Unicast Address) because ULAs do not have global
reachability". If not, then why not?
3. Why are you citing RFC4864? That is about firewalling, not uniqueness.

Suggested replacement text: "Note that, while ULAs are global-scope
addresses, they do not have global reachability. Therefore, address
selection algorithms distinguish between ULAs and GUA (Global Unicast
Address) [RFC 6724]".

II. "ULA provides an internal address independence capability in IPv6 that
is similar to how [RFC1918] is commonly used." This is incorrect, because
commonly, a host's RFC1918 address is the only address on the host, and
 RFC1918 addresses communicate to the outside world via NAT. This is not
the case for ULA.

III. "what parameters have to be assembled or transmitted globally, by a
separate function, through an appropriate gateway/firewall, to the Internet
or to the telecom network." What does this mean? What is a "parameter" and
how does one "assemble" it, or "transmit it globally"? What could a
"separate function" be? What is the "telecom network"?

IV. "Alternatively, it could be regenerated regularly, if desired for some
reason." Can it? How regularly? If it is regenerated your ULA once a
second, how soon before collisions become likely? What about 100, 1000 or
1000000 times per second? You probably want to qualify "regularly".

V. "the network needs ULA as the on-demand and stable addressing which
doesn't need much code to support address assignment mechanisms like DHCP
or ND." I don't think this makes sense. Are you saying such nodes only
support manual address assignment? How is it possible that a sensor doesn't
support automatic address assignment due to lack of resources, but has
enough resources to implement a UI for manual address assignment?

VI. "there always be some argument that in practice the ULA+PA makes
terrible operational complexity. But it is not a ULA-specific problem; the
multiple- addresses-per-interface is an important feature of IPv6 protocol.
Running multiple prefixes in IPv6 might be very common, and we need to
adapt this new operational model than that in IPv4." This text does not
make sense. Just because having multiple global-scope addresses is a
feature of IPv6 doesn't mean that you must have multiple global-scope
addresses. For example, you can use only global addresses and have no
routing complexity.

VII. "Another issue is mentioned in [RFC5220], there is a possibility that
the longest matching rule will not be able to choose the correct address
between ULAs and global unicast addresses for correct intra-site and
extra-site communication." This text should be removed, since this problem
was addressed in RFC 6724,

VIII. "In [RFC6724] , it claimed that a site-specific policy entry can be
used to cause ULAs within a site to be preferred over global addresses.".
Why is this text here? Is it problem? Is it a solution?

IX. "the pref64 is a very good use of ULA.". Actually, it isn't. Per RFC
6724, using ULA for the pref64 means that devices with an IPv4 address
(e.g., using 464xlat) - will use IPv4 in preference to IPv6. Thus, there is
no point in deploying NAT64 with ULA, because it will only be used for
IPv6-only services (which basically don't exist). If the statement "Using
ULA for Pref64 is deployed" refers to T-Mobile USA (which it might, given
that T-Mobile USA is the affiliation of one of the authors), then that
statement is no longer true - AIUI, the ULA pref64 was renumbered to GUA
because of this problem. So I think this section should be removed.

Regards,
Lorenzo

On Mon, May 20, 2013 at 12:54 PM, Liubing (Leo) <[email-masked]>wrote:

> Hi, Dear all
>
> This new ietf-00 draft is based on
> http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis-05
> During the last IETF meeting, we had a significant amount of discussion on
> this draft. And lots of comments were received in the meeting and mail
> discussion. Thanks for all your contributions.
>
> However, we couldn't include all your suggestions in the new ietf-00
> version. Since the adoption call was based on the old -05 I-D, and we still
> have much controversy on some aspects. So the ietf-00 only did some minor
> revisions and added a bit general consensus discussion (see section 4).
>

---

From: Owen DeLong <[email-masked]>
Date: Mon, 20 May 2013 21:29:08 -0700

+1 I agree with Lorenzo on all counts.

Owen

On May 20, 2013, at 12:49 AM, Lorenzo Colitti <[email-masked]> wrote:

> Bing,
> 
> a few comments:
> 
> I. "Notice that, as described in [RFC4864], in practice, applications may treat ULAs like global-scope addresses, but address selection algorithms may need to distinguish between ULAs and ordinary GUA Global-scope Unicast Address) to ensure bidirectional communications."
> 
> 1. "In practice, applications may treat ULAs like global-scope addresses" is incorrect. ULAs are global-scope addresses, and we should state that they are. 
> 2.  "Address selection algorithms may need to distinguish between ULAs and ordinary GUA (Global-scope Unicast Address) to ensure bidirectional communications." Which algorithms? Do the ones in RFC 6724 do this? If so, we should simply say that "applications distinguish between ULAs and GUA (Global-scope Unicast Address) because ULAs do not have global reachability". If not, then why not?
> Suggested replacement text: "Note that, while ULAs are global-scope addresses, they do not have global reachability. Therefore, address selection algorithms distinguish between ULAs and GUA (Global Unicast Address) [RFC 6724]".
> 
> 
> II. "ULA provides an internal address independence capability in IPv6 that is similar to how [RFC1918] is commonly used." This is incorrect, because commonly, a host's RFC1918 address is the only address on the host, and  RFC1918 addresses communicate to the outside world via NAT. This is not the case for ULA.
> 
> 
> III. "what parameters have to be assembled or transmitted globally, by a separate function, through an appropriate gateway/firewall, to the Internet or to the telecom network." What does this mean? What is a "parameter" and how does one "assemble" it, or "transmit it globally"? What could a "separate function" be? What is the "telecom network"?
> 
> 
> IV. "Alternatively, it could be regenerated regularly, if desired for some reason." Can it? How regularly? If it is regenerated your ULA once a second, how soon before collisions become likely? What about 100, 1000 or 1000000 times per second? You probably want to qualify "regularly".
> 
> 
> V. "the network needs ULA as the on-demand and stable addressing which doesn't need much code to support address assignment mechanisms like DHCP or ND." I don't think this makes sense. Are you saying such nodes only support manual address assignment? How is it possible that a sensor doesn't support automatic address assignment due to lack of resources, but has enough resources to implement a UI for manual address assignment?
> 
> 
> VI. "there always be some argument that in practice the ULA+PA makes terrible operational complexity. But it is not a ULA-specific problem; the multiple- addresses-per-interface is an important feature of IPv6 protocol. Running multiple prefixes in IPv6 might be very common, and we need to adapt this new operational model than that in IPv4." This text does not make sense. Just because having multiple global-scope addresses is a feature of IPv6 doesn't mean that you must have multiple global-scope addresses. For example, you can use only global addresses and have no routing complexity.
> 
> 
> VII. "Another issue is mentioned in [RFC5220], there is a possibility that the longest matching rule will not be able to choose the correct address between ULAs and global unicast addresses for correct intra-site and extra-site communication." This text should be removed, since this problem was addressed in RFC 6724,
> 
> 
> VIII. "In [RFC6724] , it claimed that a site-specific policy entry can be used to cause ULAs within a site to be preferred over global addresses.". Why is this text here? Is it problem? Is it a solution?
> 
> 
> IX. "the pref64 is a very good use of ULA.". Actually, it isn't. Per RFC 6724, using ULA for the pref64 means that devices with an IPv4 address (e.g., using 464xlat) - will use IPv4 in preference to IPv6. Thus, there is no point in deploying NAT64 with ULA, because it will only be used for IPv6-only services (which basically don't exist). If the statement "Using ULA for Pref64 is deployed" refers to T-Mobile USA (which it might, given that T-Mobile USA is the affiliation of one of the authors), then that statement is no longer true - AIUI, the ULA pref64 was renumbered to GUA because of this problem. So I think this section should be removed.
> 
> Regards,
> Lorenzo
> 
> 
> On Mon, May 20, 2013 at 12:54 PM, Liubing (Leo) <[email-masked]> wrote:
> Hi, Dear all
>

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 21 May 2013 07:13:02 +0000

Hi, Lorenzo

Thanks for your careful review and comments. Please see replies inline.

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Monday, May 20, 2013 3:50 PM
To: Liubing (Leo)
Cc: [email-masked]; [email-masked]
Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations

Bing,

a few comments:

1. "In practice, applications may treat ULAs like global-scope addresses" is incorrect. ULAs are global-scope addresses, and we should state that they are.
[Bing] They are designed intended to be globally unique, but they are clearly defined as "local IPv6 addresses". And the sentence actually comes from RFC4193, see section 1.

2.  "Address selection algorithms may need to distinguish between ULAs and ordinary GUA (Global-scope Unicast Address) to ensure bidirectional communications." Which algorithms? Do the ones in RFC 6724 do this? If so, we should simply say that "applications distinguish between ULAs and GUA (Global-scope Unicast Address) because ULAs do not have global reachability". If not, then why not?
[Bing] Yes, it meant the RFC6724, we mentioned 6724 in other places, but we also need mention it here. Will do in the next version. Thanks.

3. Why are you citing RFC4864? That is about firewalling, not uniqueness.
[Bing] RFC4864 is meaningful in the use case discuss, but indeed not necessary here, will update. Thanks.

Suggested replacement text: "Note that, while ULAs are global-scope addresses, they do not have global reachability. Therefore, address selection algorithms distinguish between ULAs and GUA (Global Unicast Address) [RFC 6724]".
[Bing] As said above, I think the sentence would be good if delete "while ULAs are global-scope addresses".

II. "ULA provides an internal address independence capability in IPv6 that is similar to how [RFC1918] is commonly used." This is incorrect, because commonly, a host's RFC1918 address is the only address on the host, and  RFC1918 addresses communicate to the outside world via NAT. This is not the case for ULA.
[Bing] From the address independence perspective, they are similar. But I agree with you the expression might not be accurate, will update, thanks.

III. "what parameters have to be assembled or transmitted globally, by a separate function, through an appropriate gateway/firewall, to the Internet or to the telecom network." What does this mean? What is a "parameter" and how does one "assemble" it, or "transmit it globally"? What could a "separate function" be? What is the "telecom network"?
[Bing] The expression is odd, sorry, will update. The point we wanted to make was the well know prefix is convenient for cross-domain policies.

IV. "Alternatively, it could be regenerated regularly, if desired for some reason." Can it? How regularly? If it is regenerated your ULA once a second, how soon before collisions become likely? What about 100, 1000 or 1000000 times per second? You probably want to qualify "regularly".
[Bing] Generally, "regularly regenerated" on-demand. Say, upper layer wants a new ULA for a new session id. I think maybe we don't need to worry about the regeneration rate that might increase the collision probability significantly.  That might only concern in a scientific research of collision.

V. "the network needs ULA as the on-demand and stable addressing which doesn't need much code to support address assignment mechanisms like DHCP or ND." I don't think this makes sense. Are you saying such nodes only support manual address assignment? How is it possible that a sensor doesn't support automatic address assignment due to lack of resources, but has enough resources to implement a UI for manual address assignment?
[Bing] The lack of resources mainly regarding the network environment, there might not be a comprehensive network provisioning environment for the nodes. If they can be pre-configured with ULA, say, hard-coded in the embedded system, like the MAC addresses in every single NIC or self-generating a ULA, then they could make ad-hoc networking without address provisioning procedures.
And if they need to connect outside, then just add a NPTv6 gateway and make it as the default gateway. This is to achieve a minimal network environment/management burden.

VI. "there always be some argument that in practice the ULA+PA makes terrible operational complexity. But it is not a ULA-specific problem; the multiple- addresses-per-interface is an important feature of IPv6 protocol. Running multiple prefixes in IPv6 might be very common, and we need to adapt this new operational model than that in IPv4." This text does not make sense. Just because having multiple global-scope addresses is a feature of IPv6 doesn't mean that you must have multiple global-scope addresses. For example, you can use only global addresses and have no routing complexity.
[Bing] The ULA+PA operational complexity contains two aspect.
One is the common issue as described in the texts, running multiple prefixes in a network is new to the traditional IPv4 model, the admins need to be familiar with it in the future.
The other is about the address selection, without the new rules in RFC6724, it might be problematic to run ULA+PA, when we discuss this in 6renum, Eric Vyncke reported they had a terrible experience of using this mode several years ago. In last IETF, we briefly discussed this issue again,  and we thought it was probably because of the old address selection algorithms that didn't distinguish ULA from GUA.

VII. "Another issue is mentioned in [RFC5220], there is a possibility that the longest matching rule will not be able to choose the correct address between ULAs and global unicast addresses for correct intra-site and extra-site communication." This text should be removed, since this problem was addressed in RFC 6724,
[Bing] Ok, will update. Thanks.

VIII. "In [RFC6724] , it claimed that a site-specific policy entry can be used to cause ULAs within a site to be preferred over global addresses.". Why is this text here? Is it problem? Is it a solution?
[Bing] We might need to move it to a proper place.

IX. "the pref64 is a very good use of ULA.". Actually, it isn't. Per RFC 6724, using ULA for the pref64 means that devices with an IPv4 address (e.g., using 464xlat) - will use IPv4 in preference to IPv6. Thus, there is no point in deploying NAT64 with ULA, because it will only be used for IPv6-only services (which basically don't exist). If the statement "Using ULA for Pref64 is deployed" refers to T-Mobile USA (which it might, given that T-Mobile USA is the affiliation of one of the authors), then that statement is no longer true - AIUI, the ULA pref64 was renumbered to GUA because of this problem. So I think this section should be removed.
[Bing] Thanks for this valuable information. I'll ask our co-author to identify it.

Best regards,
Bing

Regards,
Lorenzo

On Mon, May 20, 2013 at 12:54 PM, Liubing (Leo) <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Dear all

Many thanks!

B.R.
Bing

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
> Of [email-masked]<mailto:[email-masked]>
> To: [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Erik Kline <[email-masked]>
Date: Tue, 21 May 2013 16:38:24 +0900

> treat ULAs like global-scope addresses, but address selection algorithms may
> need to distinguish between ULAs and ordinary GUA Global-scope Unicast
> 1. "In practice, applications may treat ULAs like global-scope addresses" is
> incorrect. ULAs are global-scope addresses, and we should state that they
> are.
>
> [Bing] They are designed intended to be globally unique, but they are
> clearly defined as “local IPv6 addresses”. And the sentence actually comes
> from RFC4193, see section 1.

No, they are global addresses.  Quoting from section 3.3 of 4193 (the
very first sentence): "By default, the scope of these addresses is
global."

> [Bing] As said above, I think the sentence would be good if delete “while
> ULAs are global-scope addresses”.

Reminder: they are global addresses.  See 4193#section-3.3 (quoted
above) and 6724#section-3.1:

"Also, note that ULAs are considered as global, not site-local, scope
but are handled via the prefix policy table as discussed in Section
10.6."

Let's not try to remake ULAs into IPv6 RFC1918 space.

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 21 May 2013 07:48:56 +0000

Hi, Erik

> very first sentence): "By default, the scope of these addresses is

[Bing] Oops, my misunderstanding it. Thanks for correcting.

> Let's not try to remake ULAs into IPv6 RFC1918 space.
[Bing] Yes. Thanks.

Best regards,
Bing

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 21 May 2013 17:13:05 +0900

On Tue, May 21, 2013 at 4:13 PM, Liubing (Leo) <[email-masked]>wrote:

> they are. ****
Ah, I see. So the problem here is that even though you copied and pasted
the sentence, the difference in context makes the word "may" have two
different meanings.

When RFC 4193 says "In practice, applications may treat these addresses
like global scoped addresses", what it means is that applications *are
permitted* to treat these addresses as global addresses. This is because
RFC 4193 is the specification that is defining these addresses, is
therefore normative, and is saying what applications are allowed to do.

However, in this draft, which is not normative and is intended to describe
usage of these addresses, saying "may treat these addresses like global
scope addresses" suggests that applications "may" treat them like global
scope addresses, but may also treat them differently. So basically, since
this document is not normative, saying "may" is ambiguous.

I suggest resolving the ambiguity by saying something that is more precise
- i.e., that ULAs are global-scope addresses. This is explicitly addressed
in RFC 4193 section 3.3 ("by default, the scope of these addresses is
global") and RFC 6724 section 3.1 ("note that ULAs are considered as global
[...] scope").

As for them being defined as "local IPv6 addresses", RFC 4193 does not
define them as "local IPv6 addresses". "Local IPv6 addresses" is just an
abbreviation used in RFC 4193, which says "These addresses are called
Unique Local IPv6 Unicast Addresses and are abbreviated in this document as
Local IPv6 addresses."

> ULAs are global-scope addresses”.
Why are you suggesting deleting that text? Do you disagree that ULAs have
global scope? They do have global scope, as specified by both RFC 4193 and
RFC 6724.

> ****
> [Bing] Generally, “regularly regenerated” on-demand. Say, upper layer
> wants a new ULA for a new session id. I think maybe we don’t need to worry
> about the regeneration rate that might increase the collision probability
> significantly.  That might only concern in a scientific research of
> collision.
>
No, the probability is much higher than you think. See RFC 4193 section
3.2.3. If I'm reading that section correctly, if you generate 10000 ULAs
you'll get a collision 1 in 500k times. If you generate 100000 (e.g., if
you regenerate them once a second, for one day) you'll get a collision once
in 1000 times. And so on.

> ****
>
> ** V. "the network needs ULA as the on-demand and stable addressing which
> [Bing] The lack of resources mainly regarding the network environment,
> there might not be a comprehensive network provisioning environment for the
> nodes. If they can be pre-configured with ULA, say, hard-coded in the
> embedded system, like the MAC addresses in every single NIC or
> self-generating a ULA, then they could make ad-hoc networking without
> address provisioning procedures.
>
How are those nodes going to find the MAC address of the link router to
communicate off-link? If they can't do this, then you don't need ULA, you
can just use link-local. If they can do this, then they must support router
advertisements or similar. If they support router advertisements, then they
can use autoconfiguration.

> ****
> [Bing] The ULA+PA operational complexity contains two aspect.****
>
> One is the common issue as described in the texts, running multiple
> prefixes in a network is new to the traditional IPv4 model, the admins need
> to be familiar with it in the future.
>
No, because having multiple prefixes introduces operational complexity even
if the admins understand multiple prefixes. All things being equal, having
only one prefix (e.g., a global prefix) is always going to be simpler than
having two.

In other words: what you're saying is "let's create complexity, because
admins will need to understand the complexity anyway". What I'm saying is
that while they need to understand the complexity, we don't have to create
the complexity if we don't need it.

>  ****
>
> The other is about the address selection, without the new rules in
> RFC6724, it might be problematic to run ULA+PA, when we discuss this in
> 6renum, Eric Vyncke reported they had a terrible experience of using this
> mode several years ago. In last IETF, we briefly discussed this issue
> again,  and we thought it was probably because of the old address selection
> algorithms that didn’t distinguish ULA from GUA.
>
Then this section needs to be worded more clearly once the cause is clearly
determined and the problem clearly documented.

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 21 May 2013 09:34:44 +0000

Hi, Lorenzo

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Tuesday, May 21, 2013 4:13 PM
To: Liubing (Leo)
Cc: [email-masked]; [email-masked]
Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations

On Tue, May 21, 2013 at 4:13 PM, Liubing (Leo) <[email-masked]<mailto:[email-masked]>> wrote:

1. "In practice, applications may treat ULAs like global-scope addresses" is incorrect. ULAs are global-scope addresses, and we should state that they are.
[Bing] They are designed intended to be globally unique, but they are clearly defined as "local IPv6 addresses". And the sentence actually comes from RFC4193, see section 1.
Ah, I see. So the problem here is that even though you copied and pasted the sentence, the difference in context makes the word "may" have two different meanings.

When RFC 4193 says "In practice, applications may treat these addresses like global scoped addresses", what it means is that applications *are permitted* to treat these addresses as global addresses. This is because RFC 4193 is the specification that is defining these addresses, is therefore normative, and is saying what applications are allowed to do.

However, in this draft, which is not normative and is intended to describe usage of these addresses, saying "may treat these addresses like global scope addresses" suggests that applications "may" treat them like global scope addresses, but may also treat them differently. So basically, since this document is not normative, saying "may" is ambiguous.

I suggest resolving the ambiguity by saying something that is more precise - i.e., that ULAs are global-scope addresses. This is explicitly addressed in RFC 4193 section 3.3 ("by default, the scope of these addresses is global") and RFC 6724 section 3.1 ("note that ULAs are considered as global [...] scope").

As for them being defined as "local IPv6 addresses", RFC 4193 does not define them as "local IPv6 addresses". "Local IPv6 addresses" is just an abbreviation used in RFC 4193, which says "These addresses are called Unique Local IPv6 Unicast Addresses and are abbreviated in this document as Local IPv6 addresses."

[Bing] Will update accordingly. Thanks.
Suggested replacement text: "Note that, while ULAs are global-scope addresses, they do not have global reachability. Therefore, address selection algorithms distinguish between ULAs and GUA (Global Unicast Address) [RFC 6724]".
[Bing] As said above, I think the sentence would be good if delete "while ULAs are global-scope addresses".
Why are you suggesting deleting that text? Do you disagree that ULAs have global scope? They do have global scope, as specified by both RFC 4193 and RFC 6724.
 [Bing] It was my misunderstanding of it, as explained to Erik.
IV. "Alternatively, it could be regenerated regularly, if desired for some reason." Can it? How regularly? If it is regenerated your ULA once a second, how soon before collisions become likely? What about 100, 1000 or 1000000 times per second? You probably want to qualify "regularly".
[Bing] Generally, "regularly regenerated" on-demand. Say, upper layer wants a new ULA for a new session id. I think maybe we don't need to worry about the regeneration rate that might increase the collision probability significantly.  That might only concern in a scientific research of collision.
No, the probability is much higher than you think. See RFC 4193 section 3.2.3. If I'm reading that section correctly, if you generate 10000 ULAs you'll get a collision 1 in 500k times. If you generate 100000 (e.g., if you regenerate them once a second, for one day) you'll get a collision once in 1000 times. And so on.
[Bing] In theory, I agree with you. But the point here is where do we need to change the ULA so frequently? For random draw? I can hardly imagine a use case of that.
 V. "the network needs ULA as the on-demand and stable addressing which doesn't need much code to support address assignment mechanisms like DHCP or ND." I don't think this makes sense. Are you saying such nodes only support manual address assignment? How is it possible that a sensor doesn't support automatic address assignment due to lack of resources, but has enough resources to implement a UI for manual address assignment?
[Bing] The lack of resources mainly regarding the network environment, there might not be a comprehensive network provisioning environment for the nodes. If they can be pre-configured with ULA, say, hard-coded in the embedded system, like the MAC addresses in every single NIC or self-generating a ULA, then they could make ad-hoc networking without address provisioning procedures.
How are those nodes going to find the MAC address of the link router to communicate off-link? If they can't do this, then you don't need ULA, you can just use link-local. If they can do this, then they must support router advertisements or similar. If they support router advertisements, then they can use autoconfiguration.
[Bing] Surely they need to support SLAAC, it's a basic IPv6 function , the draft specifically noted this point.  But if the sensors are in a MANET, then the autoconfiguration is different with the traditional wired SLAAC, since MANET is based on a multi hop topology. ULA is suitable for this scenario, however, current text seems not sufficient/clear, will modify later.
VI. "there always be some argument that in practice the ULA+PA makes terrible operational complexity. But it is not a ULA-specific problem; the multiple- addresses-per-interface is an important feature of IPv6 protocol. Running multiple prefixes in IPv6 might be very common, and we need to adapt this new operational model than that in IPv4." This text does not make sense. Just because having multiple global-scope addresses is a feature of IPv6 doesn't mean that you must have multiple global-scope addresses. For example, you can use only global addresses and have no routing complexity.
[Bing] The ULA+PA operational complexity contains two aspect.
One is the common issue as described in the texts, running multiple prefixes in a network is new to the traditional IPv4 model, the admins need to be familiar with it in the future.
No, because having multiple prefixes introduces operational complexity even if the admins understand multiple prefixes. All things being equal, having only one prefix (e.g., a global prefix) is always going to be simpler than having two.

In other words: what you're saying is "let's create complexity, because admins will need to understand the complexity anyway". What I'm saying is that while they need to understand the complexity, we don't have to create the complexity if we don't need it.
[Bing] No, I'm not say that. ULA+PA is identified as beneficial use case in 6renum and Homenet. So the admins need to adapt the complexity if they want the benefit.

The other is about the address selection, without the new rules in RFC6724, it might be problematic to run ULA+PA, when we discuss this in 6renum, Eric Vyncke reported they had a terrible experience of using this mode several years ago. In last IETF, we briefly discussed this issue again,  and we thought it was probably because of the old address selection algorithms that didn't distinguish ULA from GUA.
Then this section needs to be worded more clearly once the cause is clearly determined and the problem clearly documented.
[Bing] Sure, agree.

B.R.
Bing

---

From: Tim Chown <[email-masked]>
Date: Tue, 21 May 2013 10:54:25 +0100

On 21 May 2013, at 09:13, Lorenzo Colitti <[email-masked]> wrote:

> On Tue, May 21, 2013 at 4:13 PM, Liubing (Leo) <[email-masked]> wrote:

It will of course be simpler, the open question being what is meant by "all things being equal".

In a homenet, there may be cases where there is no external connectivity, in some cases where none has yet been established (rather than it having been there and gone away). There may be devices that have ULAs "burnt in", for which those ULAs need to be routed around the scope of the homenet.  And there is an argument for ULAs for stable connectivity internally in the face of whatever happens to external prefix(es)/connectivity.

In a dual-stack homenet, there will be at least two prefixes, one IPv4, one IPv6.

Which reminds me, I would like to see this document do some deeper analysis of the issue raised after IETF86, regarding "ULAs on by default" alongside IPv4/NAT. That thread, discussing the practical issues, ran to 150+ emails before fizzling out without any specific proposed text, either for Bing's draft or the homenet arch. I recall that Ole's point on this was that *if* hosts supported RFC4191 RIO, then ULA routes could be added without a default route, and dependencies/timeouts on ICMPv6 redirects avoided. And RFC6204bis ULA-5 recommends that behaviour (along with L-3). The little snag is that current OSes certainly don't all support RFC4191.

> In other words: what you're saying is "let's create complexity, because admins will need to understand the complexity anyway". What I'm saying is that while they need to understand the complexity,…

Well, in a home network there will be no admins. Plug and play is what we want. But connection timeouts are equally what we do not want.

Tim

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 21 May 2013 13:21:37 +0200

Le 21/05/2013 09:38, Erik Kline a écrit :
>> I. "Notice that, as described in [RFC4864], in practice,
>> applications may treat ULAs like global-scope addresses, but
>> address selection algorithms may need to distinguish between ULAs
>> and ordinary GUA Global-scope Unicast Address) to ensure
>> bidirectional communications."
>>
>>
>>
>> 1. "In practice, applications may treat ULAs like global-scope
>> addresses" is incorrect. ULAs are global-scope addresses, and we
>> should state that they are.
>>
>> [Bing] They are designed intended to be globally unique, but they
>> are clearly defined as “local IPv6 addresses”. And the sentence
>> actually comes from RFC4193, see section 1.
>
> No, they are global addresses.  Quoting from section 3.3 of 4193
> (the very first sentence): "By default, the scope of these addresses
> is global."
>
>
>> Suggested replacement text: "Note that, while ULAs are
>> global-scope addresses, they do not have global reachability.
>> Therefore, address selection algorithms distinguish between ULAs
>> and GUA (Global Unicast Address) [RFC 6724]".
>>
>> [Bing] As said above, I think the sentence would be good if delete
>> “while ULAs are global-scope addresses”.
>
> Reminder: they are global addresses.

ULAs are:
- globaly unique to the extent their automatic generation guarantees
   that.
- globally scoped, have scope == global.
- not routable in the public domain, non publicly routable, not public,
   not routable in the DFZ (default free zone).

Alex

> See 4193#section-3.3 (quoted above) and 6724#section-3.1:
>
> "Also, note that ULAs are considered as global, not site-local,
> scope but are handled via the prefix policy table as discussed in
> Section 10.6."
>
>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Owen DeLong <[email-masked]>
Date: Tue, 21 May 2013 04:33:12 -0700

On May 21, 2013, at 12:13 AM, Liubing (Leo) <[email-masked]> wrote:

> [Bing] They are designed intended to be globally unique, but they are clearly defined as “local IPv6 addresses”. And the sentence actually comes from RFC4193, see section 1.
>  

There is a subtlety to the language here that is important.

SCOPE has a specific meaning WRT IPv6 addresses. While ULAs are "Local" USE addresses, they are not Local SCOPE addresses. They are most definitely global scope addresses as that is meant in IPv6.

I don't see a reference to "local scope" in RFC 4193 section 1. However, even if there is, we should not duplicate that error here.

> [Bing] As said above, I think the sentence would be good if delete “while ULAs are global-scope addresses”.

Why? ULAs ARE global scope addresses. While they are not globally routed, they are of global scope. Currently there are only two defined scopes in IPv6… { Global , Link-Local }. There was a third scope (Site-Local), but those were deprecated prior to the creation of ULA.

> [Bing] Generally, “regularly regenerated” on-demand. Say, upper layer wants a new ULA for a new session id. I think maybe we don’t need to worry about the regeneration rate that might increase the collision probability significantly.  That might only concern in a scientific research of collision.

That really depends on whether or not there is a bound on regeneration rate. I'll leave out the obvious questions about dubious nature of rapid regeneration.

> And if they need to connect outside, then just add a NPTv6 gateway and make it as the default gateway. This is to achieve a minimal network environment/management burden.

I'm sorry, but this is just silly. SLAAC is extremely lightweight in its minimal implementation and if they self-generate a ULA, your "ad-hoc" network is going to need something (probably heavier) to allow the nodes to find each other. Indeed, once you implement enough of the ND process for two nodes to find each other even for link-local addressing, there's really not much left to complete the minimal implementation of SLAAC. I think this is an extremely poor use case and not one which should be deemed acceptable. Sensors are getting smarter and more capable. Existing sensors can and do (in many cases) implement SLAAC.

> One is the common issue as described in the texts, running multiple prefixes in a network is new to the traditional IPv4 model, the admins need to be familiar with it in the future.

This is only a minor complexity and, frankly, is not new. It happens in IPv4. If both prefixes are, in fact, globally routable and/or have similar reachability profiles, then there is usually no issue.

What is unique to ULA is that it is a globally scoped address without global reachability. Now software must account for the fact that these global scope addresses are special and have an undefined limitation compared to other global scope addresses.

(One of the many reasons I think ULA is of dubious value at best).

> The other is about the address selection, without the new rules in RFC6724, it might be problematic to run ULA+PA, when we discuss this in 6renum, Eric Vyncke reported they had a terrible experience of using this mode several years ago. In last IETF, we briefly discussed this issue again,  and we thought it was probably because of the old address selection algorithms that didn’t distinguish ULA from GUA.

Right… As near as I can tell, this statement pretty much makes Lorenzo's point.

Owen

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 May 2013 08:21:15 +1200

> SCOPE has a specific meaning WRT IPv6 addresses. While ULAs are "Local" USE addresses, they are not Local SCOPE addresses. They are most definitely global scope addresses as that is meant in IPv6.

That's correct, of course. The underlying problem here is that the
notion of concentric circles of scope that was originally described
for IPv6 is simply broken. We can't fix that in the context of
describing ULA usage scenarios, so let's not try.

(For further thoughts on this see draft-carpenter-referral-ps-02
or even draft-carpenter-behave-referral-object-01.)

   Brian
> ------------------------------------------------------------------------
>

---

From: "Liubing (Leo)" <[email-masked]>
Date: Wed, 22 May 2013 01:32:15 +0000

Hi, Owen

I don't see a reference to "local scope" in RFC 4193 section 1. However, even if there is, we should not duplicate that error here.
[Bing] As replied to Lorenzo and Erik. I'll update this accordingly. Thanks for your explanation.

Why? ULAs ARE global scope addresses. While they are not globally routed, they are of global scope. Currently there are only two defined scopes in IPv6... { Global , Link-Local }. There was a third scope (Site-Local), but those were deprecated prior to the creation of ULA.
[Bing] That was my misunderstanding, I've replied to Lorenzo.

I'm sorry, but this is just silly. SLAAC is extremely lightweight in its minimal implementation and if they self-generate a ULA, your "ad-hoc" network is going to need something (probably heavier) to allow the nodes to find each other. Indeed, once you implement enough of the ND process for two nodes to find each other even for link-local addressing, there's really not much left to complete the minimal implementation of SLAAC. I think this is an extremely poor use case and not one which should be deemed acceptable. Sensors are getting smarter and more capable. Existing sensors can and do (in many cases) implement SLAAC.
[Bing] Please see the last mail to Lorenzo. Surely it should support SLAAC, and the draft clearly stated that.

Best regards,
Bing

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 24 May 2013 18:44:26 +0900

On Tue, May 21, 2013 at 6:34 PM, Liubing (Leo) <[email-masked]>wrote:

> in 1000 times. And so on.****
>
> [Bing] In theory, I agree with you. But the point here is where do we need
> to change the ULA so frequently? For random draw? I can hardly imagine a
> use case of that.
>

This is a technical document meant to provide guidance, so I'd say that
it's not appropriate to use vague words like regularly "regularly", without
stating what they mean to state what it means. Can I generate 10000 ULAs
per second, as long as I do it "regularly"? Likely not.

So you either remove the text, or state that if ULAs are generated
regularly, then collisions are possible, and perhaps provide provide an
example that calculates the probability of collision with some reasonal
value of the regeneration interval.

****
>
>     V. "the network needs ULA as the on-demand and stable addressing
> which doesn't need much code to support address assignment mechanisms like
> DHCP or ND." I don't think this makes sense. Are you saying such nodes only
> enough resources to implement a UI for manual address assignment?****
>
> address provisioning procedures.****
>
> can use autoconfiguration. ****
>
> [Bing] Surely they need to support SLAAC, it’s a basic IPv6 function , the
> draft specifically noted this point.  But if the sensors are in a MANET,
> then the autoconfiguration is different with the traditional wired SLAAC,
> since MANET is based on a multi hop topology. ULA is suitable for this
> scenario, however, current text seems not sufficient/clear, will modify
> later.
>

If they support SLAAC, then they don't need to be pre-configured, because
they can just use SLAAC to autoconfigure addresses. And if they can
autoconfigure an address, they can use a global address. So there is no
need to use ULA.

****
> routing complexity.****
> to be familiar with it in the future.****
>
>  No, because having multiple prefixes introduces operational complexity
> even if the admins understand multiple prefixes. All things being equal,
> having only one prefix (e.g., a global prefix) is always going to be
> simpler than having two.****
>
> ** **
>
> the complexity if we don't need it.****
>
> [Bing] No, I’m not say that. ULA+PA is identified as beneficial use case
> in 6renum and Homenet. So the admins need to adapt the complexity if they
> want the benefit.
>

Ok, so then just cite those documents, say that there is a trade off
between complexity and functionality, and leave it at that?

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 24 May 2013 18:46:38 +0900

On Tue, May 21, 2013 at 6:54 PM, Tim Chown <[email-masked]> wrote:

> Which reminds me, I would like to see this document do some deeper
> analysis of the issue raised after IETF86, regarding "ULAs on by default"
> alongside IPv4/NAT. That thread, discussing the practical issues, ran to
> 150+ emails before fizzling out without any specific proposed text, either
> for Bing's draft or the homenet arch. I recall that Ole's point on this was
> that *if* hosts supported RFC4191 RIO, then ULA routes could be added
> without a default route, and dependencies/timeouts on ICMPv6 redirects
> avoided. And RFC6204bis ULA-5 recommends that behaviour (along with L-3).
> The little snag is that current OSes certainly don't all support RFC4191.
>

Agreed. Though since this document is about usage guidelines, then there is
nothing much it can do except saying "currently, ULA+IPv4 or ULA+IPv4+IPv6
GUA doesn't work in the general case because OSes don't all support RFC
4191 and RFC 6724". Right?

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 24 May 2013 18:52:48 +0900

> describing ULA usage scenarios, so let's not try.

Actually, I think the underlying problem as regards this specific draft is
that ULAs were not well thought-out. They came out of a compromise where no
side got what it wanted and what we got was a poorly-understood, possibly
unusable hybrid.

Obviously that ship has sailed, but still, what we're doing here might be
putting lipstick on a pig.

---

From: Tim Chown <[email-masked]>
Date: Fri, 24 May 2013 11:34:46 +0100

On 24 May 2013, at 10:46, Lorenzo Colitti <[email-masked]> wrote:

> Agreed. Though since this document is about usage guidelines, then there is nothing much it can do except saying "currently, ULA+IPv4 or ULA+IPv4+IPv6 GUA doesn't work in the general case because OSes don't all support RFC 4191 and RFC 6724". Right?

Sounds fine to me. In my view, that's the type of analysis, and the type of implicit recommendations that this type of document can usefully make. i.e. If you are thinking about using ULAs for a specific use case, these are the considerations. If that can be used as some extra encouragement for vendors to support 4191 and 6724, that's a bonus.

I must admit that I had thought there was wider implementation of 4191 than it seems there is.

Tim

---

From: Tim Chown <[email-masked]>
Date: Fri, 24 May 2013 11:50:15 +0100

On 24 May 2013, at 10:52, Lorenzo Colitti <[email-masked]> wrote:

> On Wed, May 22, 2013 at 5:21 AM, Brian E Carpenter <[email-masked]> wrote:
> Actually, I think the underlying problem as regards this specific draft is that ULAs were not well thought-out. They came out of a compromise where no side got what it wanted and what we got was a poorly-understood, possibly unusable hybrid.
> 
> Obviously that ship has sailed, but still, what we're doing here might be putting lipstick on a pig.

Well, the homenet ship is just sounding its horn, with Mark and Ray about to toss the ropes to shore, weigh anchor and sail off.

If you disagree with the rationale for ULA usage in homenet, now's a good time to shout.

The argument in favour includes constrained devices (perhaps with ULAs "burnt in"), connectivity inside routed homenets prior to external ISP connectivity, internal connectivity during sustained ISP outages, and internal connectivity stability when external prefixes change.

An argument against is the ULA (no IPv6 GUA) + IPv4/NAT scenario. But wider implementation of 4191/6724, to enable support of the recommendations in 6204/6204-bis, would help address that concern.

Tim

---

From: "Liubing (Leo)" <[email-masked]>
Date: Fri, 24 May 2013 11:01:13 +0000

Hi, Lorenzo

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Friday, May 24, 2013 5:44 PM
To: Liubing (Leo)
Cc: [email-masked]; [email-masked]
Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations

On Tue, May 21, 2013 at 6:34 PM, Liubing (Leo) <[email-masked]<mailto:[email-masked]>> wrote:
No, the probability is much higher than you think. See RFC 4193 section 3.2.3. If I'm reading that section correctly, if you generate 10000 ULAs you'll get a collision 1 in 500k times. If you generate 100000 (e.g., if you regenerate them once a second, for one day) you'll get a collision once in 1000 times. And so on.
[Bing] In theory, I agree with you. But the point here is where do we need to change the ULA so frequently? For random draw? I can hardly imagine a use case of that.

This is a technical document meant to provide guidance, so I'd say that it's not appropriate to use vague words like regularly "regularly", without stating what they mean to state what it means. Can I generate 10000 ULAs per second, as long as I do it "regularly"? Likely not.

So you either remove the text, or state that if ULAs are generated regularly, then collisions are possible, and perhaps provide provide an example that calculates the probability of collision with some reasonal value of the regeneration interval.

[Bing] OK, I'll refine the word.

If they support SLAAC, then they don't need to be pre-configured, because they can just use SLAAC to autoconfigure addresses. And if they can autoconfigure an address, they can use a global address. So there is no need to use ULA.

[Bing] The reasoning is flawed. Let's do not mix the concepts of global addr-provisioning and autoconfiguration together. And in MANET, the SLAAC is not (fully)applicable, see http://tools.ietf.org/html/draft-ietf-autoconf-statement-04.html#section-5.2

Ok, so then just cite those documents, say that there is a trade off between complexity and functionality, and leave it at that?
[Bing] A brief complexity hint would be valuable. Thanks.

B.R.
Bing

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 24 May 2013 20:42:09 +0900

On Fri, May 24, 2013 at 8:01 PM, Liubing (Leo) <[email-masked]>wrote:

> later.****
> need to use ULA.****
> [Bing] The reasoning is flawed. Let’s do not mix the concepts of global
> addr-provisioning and autoconfiguration together.
>

Why is it flawed? You said that a use case for ULA is resource-constrained
nodes, because you can pre-assign addresses to them, and that this
simplifies the nodes. But it doesn't simplify the nodes, because even if
you pre-assign addresses, the nodes still need some mechanism (e.g., RA) in
order to find out who you can communicate to. So the nodes have to support
RAs. And if the nodes support RA, you can use autoconfiguration and you
don't need to pre-assign addresses. So you can use any type of address, not
only ULA. So this is not a use case for ULA.

> And in MANET, the SLAAC is not (fully)applicable, see
> http://tools.ietf.org/html/draft-ietf-autoconf-statement-04.html#section-5.2
>

That draft expired in 2008, so it's not really relevant. Do you have a more
up-to-date document?

On Fri, May 24, 2013 at 8:01 PM, Liubing (Leo) <[email-masked]>wrote:

>  Hi, Lorenzo****
>
> ** **
>
> *From:* Lorenzo Colitti [mailto:[email-masked]]
> *Sent:* Friday, May 24, 2013 5:44 PM
>
> *To:* Liubing (Leo)
> *Cc:* [email-masked];
> [email-masked]
> *Subject:* Re: [v6ops] A brief intro-//RE: new draft:
> draft-ietf-v6ops-ula-usage-recommendations****
>
>  ** **
>
> On Tue, May 21, 2013 at 6:34 PM, Liubing (Leo) <[email-masked]>
> wrote:****
>
>     No, the probability is much higher than you think. See RFC 4193
> section 3.2.3. If I'm reading that section correctly, if you generate 10000
> ULAs you'll get a collision 1 in 500k times. If you generate 100000 (e.g.,
> if you regenerate them once a second, for one day) you'll get a collision
> once in 1000 times. And so on.****
>
> use case of that.****
> per second, as long as I do it "regularly"? Likely not.****
>
> ** **
>
> value of the regeneration interval.****
>
> ** **
>
> [Bing] OK, I’ll refine the word.****
>
> ** **
>
> later.****
> need to use ULA.****
> [Bing] The reasoning is flawed. Let’s do not mix the concepts of global
> addr-provisioning and autoconfiguration together. And in MANET, the SLAAC
> is not (fully)applicable, see
> http://tools.ietf.org/html/draft-ietf-autoconf-statement-04.html#section-5.2
> ****
>
> ** **
>
>        VI. "there always be some argument that in practice the ULA+PA
> makes terrible operational complexity. But it is not a ULA-specific
> problem; the multiple- addresses-per-interface is an important feature of
> IPv6 protocol. Running multiple prefixes in IPv6 might be very common, and
> we need to adapt this new operational model than that in IPv4." This text
> does not make sense. Just because having multiple global-scope addresses is
> a feature of IPv6 doesn't mean that you must have multiple global-scope
> want the benefit.****
> between complexity and functionality, and leave it at that?****
>
> [Bing] A brief complexity hint would be valuable. Thanks.****
>
> ** **
>
> B.R.****
>
> Bing****
>

---

From: Anders Brandt <[email-masked]>
Date: Fri, 24 May 2013 12:30:49 +0000

Hi Lorenzo

> So you can use any type of address, not only ULA. So this is not a use case for ULA.

The ULA reasoning starts elsewhere. It is tied to a deployment use case:

When nodes are installed in a new house, there may be no internet connectivity - and even more importantly:
Even if there is internet connectivity, then you can be certain that at some time, the ISP will change your
assigned prefix.
This is critical to certain 6LoWPAN applications such as home automation.
Remote controls, sensors and wall controllers are spread all over the house.
They control lights, garage doors and aircon devices.

The addresses of the lights, garage doors and aircon devices MUST NOT change since the
remote controls, sensors and wall controllers are permanently paired to the IPv6 addresses of
lights, garage doors and aircon devices on the application level.
Only ULA prefixes provide that stability, yet ability to route within the home.
The lights, garage doors and aircon devices MAY also have global prefixes for external use by
portals and advanced clients.

Thanks,
  Anders

From: [email-masked] [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: 24. maj 2013 13:42
To: Liubing (Leo)
Cc: [email-masked]; [email-masked]
Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations

On Fri, May 24, 2013 at 8:01 PM, Liubing (Leo) <[email-masked]<mailto:[email-masked]>> wrote:

[Bing] The reasoning is flawed. Let's do not mix the concepts of global addr-provisioning and autoconfiguration together.

Why is it flawed? You said that a use case for ULA is resource-constrained nodes, because you can pre-assign addresses to them, and that this simplifies the nodes. But it doesn't simplify the nodes, because even if you pre-assign addresses, the nodes still need some mechanism (e.g., RA) in order to find out who you can communicate to. So the nodes have to support RAs. And if the nodes support RA, you can use autoconfiguration and you don't need to pre-assign addresses. So you can use any type of address, not only ULA. So this is not a use case for ULA.

And in MANET, the SLAAC is not (fully)applicable, see http://tools.ietf.org/html/draft-ietf-autoconf-statement-04.html#section-5.2

That draft expired in 2008, so it's not really relevant. Do you have a more up-to-date document?

On Fri, May 24, 2013 at 8:01 PM, Liubing (Leo) <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Lorenzo

From: Lorenzo Colitti [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, May 24, 2013 5:44 PM

To: Liubing (Leo)
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations

B.R.
Bing

---

From: Owen DeLong <[email-masked]>
Date: Fri, 24 May 2013 08:53:03 -0700

> Even if there is internet connectivity, then you can be certain that at some time, the ISP will change your

Why can you be certain of that? I understand why you cannot be certain that they won't. But I do not understand or believe that you can be certain that they will.

However, even in such a case, the router should provide the ULA in an RA. There is no need to preconfigure ULA into the node in question rather than use autoconfiguration.

> They control lights, garage doors and aircon devices.

That doesn't mean that they don't need to support RA or that they cannot autoconfigure an address. There is no valid reason these devices should have burned-in ULA. Such an addressing scheme would, in fact, be quite dysfunctional.

> lights, garage doors and aircon devices on the application level.

That's just really, REALLY bad application design. How do all of these ULA prefixes get properly routed when the devices are moved from one segment in the home to another? Do you add a giant layer of MIP complexity to the ULA in order to make that all work?

The smaller devices need to be paired with the oversight application(s). Those application(s) should provide the required directory services for them to obtain the IPv6 address(es) of other devices they need to communicate with. (The oversight application could be as simple as a dynamic DNS server or as complex as a centralized home automation management application. Whether support for pairing with more than one oversight application is required is left as an exercise for the device manufacturers.

> portals and advanced clients.

ULA prefixes can't provide that stability, either. Burning a prefix into a device is just bad juju from start to end.

It will lead to some of the same problems we have with similar systems in IPv4 where applications have built-in assumption that the network is not segmented and therefore do not function in environments where it is.

If you burn a pre-determined ULA prefix into devices, then you either:
	1)
		a)	Presume all devices that should talk to each other are on the same link.
		b)	Presume that all devices on the same link should talk to each other.
		c)	Break installations where multiple parts of the system are on different segments.
or
	2)
		a)	Require significant overhead and additional facilities (such as MIP) to make communication possible.
		b)	Create unnecessary external dependencies
		c)	Complicate and expand the codebase on resource constrained nodes.

Owen

> On Fri, May 24, 2013 at 8:01 PM, Liubing (Leo) <[email-masked]> wrote:
> [Bing] Surely they need to support SLAAC, it’s a basic IPv6 function , the draft specifically noted this point.  But if the sensors are in a MANET, then the autoconfiguration is different with the traditional wired SLAAC, since MANET is based on a multi hop topology. ULA is suitable for this scenario, however, current text seems not sufficient/clear, will modify later.
>  
> [Bing] The reasoning is flawed. Let’s do not mix the concepts of global addr-provisioning and autoconfiguration together.
>  
> On Fri, May 24, 2013 at 8:01 PM, Liubing (Leo) <[email-masked]> wrote:
> Hi, Lorenzo
>  
> On Tue, May 21, 2013 at 6:34 PM, Liubing (Leo) <[email-masked]> wrote:
> [Bing] OK, I’ll refine the word.
>  
> [Bing] Surely they need to support SLAAC, it’s a basic IPv6 function , the draft specifically noted this point.  But if the sensors are in a MANET, then the autoconfiguration is different with the traditional wired SLAAC, since MANET is based on a multi hop topology. ULA is suitable for this scenario, however, current text seems not sufficient/clear, will modify later.
>  
> [Bing] The reasoning is flawed. Let’s do not mix the concepts of global addr-provisioning and autoconfiguration together. And in MANET, the SLAAC is not (fully)applicable, see http://tools.ietf.org/html/draft-ietf-autoconf-statement-04.html#section-5.2
>  
> [Bing] No, I’m not say that. ULA+PA is identified as beneficial use case in 6renum and Homenet. So the admins need to adapt the complexity if they want the benefit.
>

---

From: Tim Chown <[email-masked]>
Date: Fri, 24 May 2013 19:21:52 +0100

In-line...

> However, even in such a case, the router should provide the ULA in an RA. There is no need to preconfigure ULA into the node in question rather than use autoconfiguration.

So in the homenet context we're listening to what the people building the constrained devices are telling us.

The ISPs are saying that it is very unlikely that the homenet's prefix will be persistent.  Certainly not in all cases.

The homenet arch assumes the use of ULAs for internal communications and stablity, and that ULA prefixes will be used in RAs.  Alongside GUA prefixes where they are also in use.

It may be that certain home gateways generate their own ULA /48's. The homenet arch talks about multiple ULA /48's potentially being in use.

> That doesn't mean that they don't need to support RA or that they cannot autoconfigure an address. There is no valid reason these devices should have burned-in ULA. Such an addressing scheme would,…

Do all 6lowpan devices support RA in the conventional sense?  Or when sleeping?

> The smaller devices need to be paired with the oversight application(s). Those application(s) should provide the required directory services for them to obtain the IPv6 address(es) of other devices…

So this would be the desired model of course, but what are the actual constraints?

> 		c)	Complicate and expand the codebase on resource constrained nodes.

In case 1) above the "burnt in" ULA could potentially still communicate across routers. I believe that's the case Anders refers to.

But again, I agree that "burnt in" addresses are highly undesirable, but are there scenarios where they are unavoidable? Perhaps we're asking in the wrong list.

Tim

---

From: joel jaeggli <[email-masked]>
Date: Fri, 24 May 2013 11:27:38 -0700

On 5/24/13 11:21 AM, Tim Chown wrote:
> In-line...
>
> On 24 May 2013, at 16:53, Owen DeLong <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>>
>> On May 24, 2013, at 05:30 , Anders Brandt 
>> <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>> Hi Lorenzo
>>> When nodes are installed in a new house, there may be no internet 
>>> connectivity - and even more importantly:
>> Why can you be certain of that? I understand why you cannot be 
>> certain that they won't. But I do not understand or believe that you 
>> can be certain that they will.
>>
>> However, even in such a case, the router should provide the ULA in an 
>> RA. There is no need to preconfigure ULA into the node in question 
>> rather than use autoconfiguration.
>
> The ISPs are saying that it is very unlikely that the homenet's prefix 
> will be persistent. Certainly not in all cases.
>
Even if the happen to be, from one ISP they certainly are not when you 
change providers. whether that is because your other one is down, or 
becasue you got $29 a month deal from at&t as an inducement to move from 
comcast doesn't seem relevant.
> The homenet arch assumes the use of ULAs for internal communications 
> and stablity, and that ULA prefixes will be used in RAs. Alongside GUA 
> prefixes where they are also in use.
>
> It may be that certain home gateways generate their own ULA /48's. The 
> homenet arch talks about multiple ULA /48's potentially being in use.
>
>> That doesn't mean that they don't need to support RA or that they 
>> cannot autoconfigure an address. There is no valid reason these 
>> devices should have burned-in ULA. Such an addressing scheme would, 
>> in fact, be quite dysfunctional.
>
>> That's just really, REALLY bad application design. How do all of 
>> these ULA prefixes get properly routed when the devices are moved 
>> from one segment in the home to another? Do you add a giant layer of 
>> MIP complexity to the ULA in order to make that all work?
>>
>> The smaller devices need to be paired with the oversight 
>> application(s). Those application(s) should provide the required 
>> directory services for them to obtain the IPv6 address(es) of other 
>> devices they need to communicate with. (The oversight application 
>> could be as simple as a dynamic DNS server or as complex as a 
>> centralized home automation management application. Whether support 
>> for pairing with more than one oversight application is required is 
>> left as an exercise for the device manufacturers.
>
>> ULA prefixes can't provide that stability, either. Burning a prefix 
>> into a device is just bad juju from start to end.
>>
>> It will lead to some of the same problems we have with similar 
>> systems in IPv4 where applications have built-in assumption that the 
>> network is not segmented and therefore do not function in 
>> environments where it is.
>>
>> a)Presume all devices that should talk to each other are on the same 
>> link.
>> b)Presume that all devices on the same link should talk to each other.
>> c)Break installations where multiple parts of the system are on 
>> different segments.
>> or
>> 2)
>> a)Require significant overhead and additional facilities (such as 
>> MIP) to make communication possible.
>> b)Create unnecessary external dependencies
>> c)Complicate and expand the codebase on resource constrained nodes.
>
> In case 1) above the "burnt in" ULA could potentially still 
> communicate across routers. I believe that's the case Anders refers to.
>
> But again, I agree that "burnt in" addresses are highly undesirable, 
> but are there scenarios where they are unavoidable? Perhaps we're 
> asking in the wrong list.
>
> Tim
>
>>
>> Owen
>>
>>> Thanks,
>>> Anders
>>> *From:[email-masked] <mailto:[email-masked]> 
>>> [mailto:[email-masked] <mailto:[email-masked]>]*On Behalf 
>>> Of*Lorenzo Colitti
>>> *Sent:*24. maj 2013 13:42
>>> *To:*Liubing (Leo)
>>> *Cc:[email-masked] <mailto:[email-masked]>; 
>>> <mailto:[email-masked]>
>>> *Subject:*Re: [v6ops] A brief intro-//RE: new draft: 
>>> draft-ietf-v6ops-ula-usage-recommendations
>>> On Fri, May 24, 2013 at 8:01 PM, Liubing (Leo) 
>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>             V. "the network needs ULA as the on-demand and stable
>>>             addressing which doesn't need much code to support
>>>             address assignment mechanisms like DHCP or ND." I don't
>>>             think this makes sense. Are you saying such nodes only
>>>             support manual address assignment? How is it possible
>>>             that a sensor doesn't support automatic address
>>>             assignment due to lack of resources, but has enough
>>>             resources to implement a UI for manual address assignment?
>>>             [Bing] The lack of resources mainly regarding the
>>>             network environment, there might not be a comprehensive
>>>             network provisioning environment for the nodes. If they
>>>             can be pre-configured with ULA, say, hard-coded in the
>>>             embedded system, like the MAC addresses in every single
>>>             NIC or self-generating a ULA, then they could make
>>>             ad-hoc networking without address provisioning procedures.
>>>
>>>         How are those nodes going to find the MAC address of the
>>>         link router to communicate off-link? If they can't do this,
>>>         then you don't need ULA, you can just use link-local. If
>>>         they can do this, then they must support router
>>>         advertisements or similar. If they support router
>>>         advertisements, then they can use autoconfiguration.
>>>         [Bing] Surely they need to support SLAAC, it’s a basic IPv6
>>>         function , the draft specifically noted this point. But if
>>>         the sensors are in a MANET, then the autoconfiguration is
>>>         different with the traditional wired SLAAC, since MANET is
>>>         based on a multi hop topology. ULA is suitable for this
>>>         scenario, however, current text seems not sufficient/clear,
>>>         will modify later.
>>>
>>>     If they support SLAAC, then they don't need to be
>>>     pre-configured, because they can just use SLAAC to autoconfigure
>>>     addresses. And if they can autoconfigure an address, they can
>>>     use a global address. So there is no need to use ULA.
>>>     [Bing] The reasoning is flawed. Let’s do not mix the concepts of
>>>     global addr-provisioning and autoconfiguration together.
>>>
>>> Why is it flawed? You said that a use case for ULA is 
>>> resource-constrained nodes, because you can pre-assign addresses to 
>>> them, and that this simplifies the nodes. But it doesn't simplify 
>>> the nodes, because even if you pre-assign addresses, the nodes still 
>>> need some mechanism (e.g., RA) in order to find out who you can 
>>> communicate to. So the nodes have to support RAs. And if the nodes 
>>> support RA, you can use autoconfiguration and you don't need to 
>>> pre-assign addresses. So you can use any type of address, not only 
>>> ULA. So this is not a use case for ULA.
>>>
>>>     And in MANET, the SLAAC is not (fully)applicable,
>>>     seehttp://tools.ietf.org/html/draft-ietf-autoconf-statement-04.html#section-5.2
>>>
>>> On Fri, May 24, 2013 at 8:01 PM, Liubing (Leo) 
>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>> Hi, Lorenzo
>>> *From:*Lorenzo Colitti [mailto:[email-masked] 
>>> <mailto:[email-masked]>]
>>> *Sent:*Friday, May 24, 2013 5:44 PM
>>>
>>> *To:*Liubing (Leo)
>>> *Cc:[email-masked] 
>>> <mailto:[email-masked]>;[email-masked] 
>>> <mailto:[email-masked]>
>>> *Subject:*Re: [v6ops] A brief intro-//RE: new draft: 
>>> draft-ietf-v6ops-ula-usage-recommendations
>>> On Tue, May 21, 2013 at 6:34 PM, Liubing (Leo) 
>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>     section 3.2.3. If I'm reading that section correctly, if you
>>>     generate 10000 ULAs you'll get a collision 1 in 500k times. If
>>>     you generate 100000 (e.g., if you regenerate them once a second,
>>>     for one day) you'll get a collision once in 1000 times. And so on.
>>>     [Bing] In theory, I agree with you. But the point here is where
>>>     do we need to change the ULA so frequently? For random draw? I
>>>     can hardly imagine a use case of that.
>>>
>>> This is a technical document meant to provide guidance, so I'd say 
>>> that it's not appropriate to use vague words like regularly 
>>> "regularly", without stating what they mean to state what it means. 
>>> Can I generate 10000 ULAs per second, as long as I do it 
>>> "regularly"? Likely not.
>>> regularly, then collisions are possible, and perhaps provide provide 
>>> an example that calculates the probability of collision with some 
>>> reasonal value of the regeneration interval.
>>>         V. "the network needs ULA as the on-demand and stable
>>>         addressing which doesn't need much code to support address
>>>         assignment mechanisms like DHCP or ND." I don't think this
>>>         makes sense. Are you saying such nodes only support manual
>>>         address assignment? How is it possible that a sensor doesn't
>>>         support automatic address assignment due to lack of
>>>         resources, but has enough resources to implement a UI for
>>>         manual address assignment?
>>>         [Bing] The lack of resources mainly regarding the network
>>>         environment, there might not be a comprehensive network
>>>         provisioning environment for the nodes. If they can be
>>>         pre-configured with ULA, say, hard-coded in the embedded
>>>         system, like the MAC addresses in every single NIC or
>>>         self-generating a ULA, then they could make ad-hoc
>>>         networking without address provisioning procedures.
>>>
>>>     How are those nodes going to find the MAC address of the link
>>>     router to communicate off-link? If they can't do this, then you
>>>     don't need ULA, you can just use link-local. If they can do
>>>     this, then they must support router advertisements or similar.
>>>     If they support router advertisements, then they can use
>>>     autoconfiguration.
>>>     [Bing] Surely they need to support SLAAC, it’s a basic IPv6
>>>     function , the draft specifically noted this point. But if the
>>>     sensors are in a MANET, then the autoconfiguration is different
>>>     with the traditional wired SLAAC, since MANET is based on a
>>>     multi hop topology. ULA is suitable for this scenario, however,
>>>     current text seems not sufficient/clear, will modify later.
>>>
>>> If they support SLAAC, then they don't need to be pre-configured, 
>>> because they can just use SLAAC to autoconfigure addresses. And if 
>>> they can autoconfigure an address, they can use a global address. So 
>>> there is no need to use ULA.
>>> [Bing] The reasoning is flawed. Let’s do not mix the concepts of 
>>> global addr-provisioning and autoconfiguration together. And in 
>>> MANET, the SLAAC is not (fully)applicable, 
>>> seehttp://tools.ietf.org/html/draft-ietf-autoconf-statement-04.html#section-5.2
>>>
>>>         VI. "there always be some argument that in practice the
>>>         ULA+PA makes terrible operational complexity. But it is not
>>>         a ULA-specific problem; the multiple-
>>>         addresses-per-interface is an important feature of IPv6
>>>         protocol. Running multiple prefixes in IPv6 might be very
>>>         common, and we need to adapt this new operational model than
>>>         that in IPv4." This text does not make sense. Just because
>>>         having multiple global-scope addresses is a feature of IPv6
>>>         doesn't mean that you must have multiple global-scope
>>>         addresses. For example, you can use only global addresses
>>>         and have no routing complexity.
>>>         One is the common issue as described in the texts, running
>>>         multiple prefixes in a network is new to the traditional
>>>         IPv4 model, the admins need to be familiar with it in the
>>>         future.
>>>
>>>     No, because having multiple prefixes introduces operational
>>>     complexity even if the admins understand multiple prefixes. All
>>>     things being equal, having only one prefix (e.g., a global
>>>     prefix) is always going to be simpler than having two.
>>>     In other words: what you're saying is "let's create complexity,
>>>     because admins will need to understand the complexity anyway".
>>>     What I'm saying is that while they need to understand the
>>>     complexity, we don't have to create the complexity if we don't
>>>     need it.
>>>     [Bing] No, I’m not say that. ULA+PA is identified as beneficial
>>>     use case in 6renum and Homenet. So the admins need to adapt the
>>>     complexity if they want the benefit.
>>>
>>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 24 May 2013 20:48:22 +0200

Le 24/05/2013 13:42, Lorenzo Colitti a écrit :
>             manual address assignment?____
>
>             networking without address provisioning procedures.____
>
>         autoconfiguration. ____
>         current text seems not sufficient/clear, will modify later.____
>
>     __ __
>
>     there is no need to use ULA.____
>
>     __ __
>
> them, and that this simplifies the nodes. But it doesn't simplify the
> nodes, because even if you pre-assign addresses, the nodes still need
> some mechanism (e.g., RA) in order to find out who you can communicate
> to. So the nodes have to support RAs. And if the nodes support RA, you
> can use autoconfiguration and you don't need to pre-assign addresses. So
> you can use any type of address, not only ULA. So this is not a use case
> for ULA.

RA could be used to just communicate the default route, not the link 
prefix - that makes for a smaller RA which is ok for constrained devices.

Actually, RA may not be needed at all for a constrained device.  You 
could have a constrained device that just knows its default route.

Alex

>     Hi, Lorenzo____
>     __ __
>     *Cc:* [email-masked] <mailto:[email-masked]>;
>     draft-ietf-v6ops-ula-usage-recommendations____
>
>     __ __
>
>     <[email-masked] <mailto:[email-masked]>> wrote:____
>
>         for one day) you'll get a collision once in 1000 times. And so
>         on.____
>
>         can hardly imagine a use case of that.____
>
>     __ __
>
>     "regularly"? Likely not.____
>
>     __ __
>
>     reasonal value of the regeneration interval.____
>
>     __ __
>
>     [Bing] OK, I’ll refine the word.____
>
>     __ __
>
>             manual address assignment?____
>
>             networking without address provisioning procedures.____
>
>         autoconfiguration. ____
>         current text seems not sufficient/clear, will modify later.____
>
>     __ __
>
>     there is no need to use ULA.____
>
>     __ __
>
>     MANET, the SLAAC is not (fully)applicable, see
>     http://tools.ietf.org/html/draft-ietf-autoconf-statement-04.html#section-5.2____
>
>     __ __
>
>             and have no routing complexity.____
>
>             [Bing] The ULA+PA operational complexity contains two
>             aspect.____
>
>             future.____
>         prefix) is always going to be simpler than having two.____
>
>         ____
>
>         need it.____
>         complexity if they want the benefit.____
>
>     __ __
>
>     between complexity and functionality, and leave it at that?____
>
>     [Bing] A brief complexity hint would be valuable. Thanks.____
>
>     __ __
>
>     B.R.____
>
>     Bing____
>
>
>
>

---

From: Owen DeLong <[email-masked]>
Date: Fri, 24 May 2013 11:45:59 -0700

> The ISPs are saying that it is very unlikely that the homenet's prefix will be persistent.  Certainly not in all cases.
Correct... This means that you cannot count on it persisting. I agree.

That is not the same as being able to count on it changing. There will be cases where it does not change. For example, my home has a direct ARIN IPv6 assignment. I realize this is not necessarily the norm, but it's also not out of the question. Many other homes I know of subscribe to business class services in order to get persistent addressing. I have no reason to believe this practice will be less common in the future.

> The homenet arch assumes the use of ULAs for internal communications and stablity, and that ULA prefixes will be used in RAs.  Alongside GUA prefixes where they are also in use.

Understood. I think it's a horrible assumption (per my previous example), but I understand the reasoning behind it.

> It may be that certain home gateways generate their own ULA /48's. The homenet arch talks about multiple ULA /48's potentially being in use.

Sure.

> Do all 6lowpan devices support RA in the conventional sense?  Or when sleeping?

I don't know. Certainly, they should support RA. They don't really need to do so when sleeping as they can send an RS when they wake up if necessary.

> So this would be the desired model of course, but what are the actual constraints?

I don't know. My point is that I don't believe the IETF should be designing RFCs around the brokenness of current designs. Rather we should document the reasons such designs are broken and encourage the vendors to make appropriate changes.

> In case 1) above the "burnt in" ULA could potentially still communicate across routers. I believe that's the case Anders refers to.

Only if the ULA is different on each device and the router somehow learns how to route all those prefixes.

Otherwise, you run into the following two problems:

	1.	Multiple devices with the same prefix not on the same network.
	2.	Multiple devices with different prefixes unable to recognize each other on the same network.

> But again, I agree that "burnt in" addresses are highly undesirable, but are there scenarios where they are unavoidable? Perhaps we're asking in the wrong list.

No, there are no scenarios where they are legitimately unavoidable if routing is required.

If you have a device that needs to have a BIA, then the BIA should be link-local only and the device should either use RA or some other mechanism to learn how to communicate off-link if necessary.

Owen

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 24 May 2013 20:51:05 +0200

Le 24/05/2013 17:53, Owen DeLong a écrit :
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>> Hi Lorenzo
> Why can you be certain of that? I understand why you cannot be certain
> that they won't. But I do not understand or believe that you can be
> certain that they will.
>
> That doesn't mean that they don't need to support RA or that they cannot
> autoconfigure an address. There is no valid reason these devices should
> have burned-in ULA. Such an addressing scheme would, in fact, be quite
> dysfunctional.

Not sure what you mean.

But sure a device which has its address pre-configured could go very far 
in reducing its memory/cpu print.

Alex

> That's just really, REALLY bad application design. How do all of these
> ULA prefixes get properly routed when the devices are moved from one
> segment in the home to another? Do you add a giant layer of MIP
> complexity to the ULA in order to make that all work?
>
> The smaller devices need to be paired with the oversight application(s).

?

Its sufficient for the remote apps to be preconfigured with the devices' 
addresses, no need to preconfigure the other way around.

> Those application(s) should provide the required directory services for
> them to obtain the IPv6 address(es) of other devices they need to
> communicate with. (The oversight application could be as simple as a
> dynamic DNS server or as complex as a centralized home automation
> management application. Whether support for pairing with more than one
> oversight application is required is left as an exercise for the device
> manufacturers.

Its a way of doing it.

And there are other simpler ways.

Alex

> ULA prefixes can't provide that stability, either. Burning a prefix into
> a device is just bad juju from start to end.
>
> It will lead to some of the same problems we have with similar systems
> in IPv4 where applications have built-in assumption that the network is
> not segmented and therefore do not function in environments where it is.
>
> a)Presume all devices that should talk to each other are on the same link.
> a)Require significant overhead and additional facilities (such as MIP)
> to make communication possible.
>>             address assignment? How is it possible that a sensor
>>             doesn't support automatic address assignment due to lack
>>             of resources, but has enough resources to implement a UI
>>             for manual address assignment?
>>         router to communicate off-link? If they can't do this, then
>>         you don't need ULA, you can just use link-local. If they can
>>         do this, then they must support router advertisements or
>>         similar. If they support router advertisements, then they can
>>         use autoconfiguration.
>>     they can autoconfigure an address, they can use a global address.
>>     So there is no need to use ULA.
>> can use autoconfiguration and you don't need to pre-assign addresses.
>>     generate 10000 ULAs you'll get a collision 1 in 500k times. If you
>>     generate 100000 (e.g., if you regenerate them once a second, for
>>     one day) you'll get a collision once in 1000 times. And so on.
>>     [Bing] In theory, I agree with you. But the point here is where do
>>     we need to change the ULA so frequently? For random draw? I can
>>     hardly imagine a use case of that.
>>
>> Can I generate 10000 ULAs per second, as long as I do it "regularly"?
>> Likely not.
>>         support automatic address assignment due to lack of resources,
>>         but has enough resources to implement a UI for manual address
>>         assignment?
>>         self-generating a ULA, then they could make ad-hoc networking
>>         without address provisioning procedures.
>>
>>     don't need ULA, you can just use link-local. If they can do this,
>>     then they must support router advertisements or similar. If they
>>     support router advertisements, then they can use autoconfiguration.
>>     with the traditional wired SLAAC, since MANET is based on a multi
>>     hop topology. ULA is suitable for this scenario, however, current
>>     text seems not sufficient/clear, will modify later.
>>
>> global addr-provisioning and autoconfiguration together. And in MANET,
>> the SLAAC is not (fully)applicable,
>>         makes terrible operational complexity. But it is not a
>>         ULA-specific problem; the multiple- addresses-per-interface is
>>         an important feature of IPv6 protocol. Running multiple
>>         prefixes in IPv6 might be very common, and we need to adapt
>>         this new operational model than that in IPv4." This text does
>>         not make sense. Just because having multiple global-scope
>>         addresses is a feature of IPv6 doesn't mean that you must have
>>         multiple global-scope addresses. For example, you can use only
>>         global addresses and have no routing complexity.
>>         multiple prefixes in a network is new to the traditional IPv4
>>         model, the admins need to be familiar with it in the future.
>>
>>     things being equal, having only one prefix (e.g., a global prefix)
>>     is always going to be simpler than having two.

---

From: Gert Doering <[email-masked]>
Date: Fri, 24 May 2013 22:36:15 +0200

Hi,

> in reducing its memory/cpu print.

As could a device without a network stack.

Your point being?

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 24 May 2013 22:39:10 +0200

Le 24/05/2013 22:36, Gert Doering a écrit :
>>> devices should have burned-in ULA. Such an addressing scheme
>>> would, in fact, be quite dysfunctional.
>>
>> Not sure what you mean.
>>
>> But sure a device which has its address pre-configured could go
>> very far in reducing its memory/cpu print.
>

My point being that ULA could be very much appropriated for constrained
devices (without SLAAC) - and yet have a network stack.

Alex

>
> Gert Doering -- NetMaster
>

---

From: joel jaeggli <[email-masked]>
Date: Fri, 24 May 2013 14:11:20 -0700

>> in reducing its memory/cpu print.
A decade ago dallas-semiconductor had a working v6 stack on a 8051 based 
8 bit microcontroller with 64k of rom...

There seems to be small but quite persistent faction that insists on the 
notion that functionally limited systems are incapable of operating 
around the incredibly basic set of functional building blocks for an 
ipv6 network on their link-layer of choice. Frankly I don't see it. IETF 
participants have invested a lot of productive time and energy in 
low-power/low signalling/low bandwidth embedded networking, stripping 
out the things that make it flexible robust and easy to deploy in the 
interest of something that might notionally be more compact then the 
toolkit we have at present, seems incredibly limiting.

Can you do it? Sure. In fact, nobody is going to stop you.

Is it an "improvement"? Maybe by some measure, but I kind of doubt it.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 24 May 2013 23:19:45 +0200

Le 24/05/2013 23:11, joel jaeggli a écrit :
>>>> cannot

That was then.

Since then even smaller platforms are tried.

> ipv6 network on their link-layer of choice.

An autoconfiguration feature is a functionality, and compares badly to 
whatever static preconfiguration, in terms of memory/cpu constraints.

I really dont see why arguing against this, it's simply basics.

Alex

  Frankly I don't see it. IETF

---

From: joel jaeggli <[email-masked]>
Date: Fri, 24 May 2013 15:09:47 -0700

On 5/24/13 5:30 AM, Anders Brandt wrote:
 > connectivity - and even more importantly: Even if there is internet
 > connectivity, then you can be certain that at some time, the ISP will
 > change your assigned prefix.
 >
 > Remote controls, sensors and wall controllers are spread all over the
 > house. They control lights, garage doors and aircon devices.
 >
 > The addresses of the lights, garage doors and aircon devices MUST NOT
 > change since the remote controls, sensors and wall controllers are
 > permanently paired to the IPv6 addresses of lights, garage doors and
 > aircon devices on the application level.
 >

If we look at how these things are done today, I think it's pretty rare 
to see consumer oriented devices that are bound by ip address. rather 
that binding is some kind of upper layer activity. I can swap out my 
router or change my numbering plan and to consumer devices in my house 
will accommodate that without configuration change.

certainly ipso/coap devices do not envision permenent ip bindings and 
likewise callout static assignment as fragile, e.g.

https://datatracker.ietf.org/doc/draft-ietf-core-coap/

7.2. Resource Discovery

The discovery of resources offered by a CoAP endpoint is extremely
important in machine-to-machine applications where there are no
humans in the loop and static interfaces result in fragility.

you may consider 6lowpan wifi enabled lightbulbs to be something of a 
gimmick (I doubt philips/nxp does) but they're certainly not sensitive 
to renumbering and nor should other devices.

 > The lights, garage doors and aircon devices MAY also have global
 > prefixes for external use by portals and advanced clients.
 >
 >
 >
 > Thanks,
 >
 > Anders
 >
 >
 >
 >
 >
 > *From:[email-masked] [mailto:[email-masked]] *On
 > Behalf Of *Lorenzo Colitti *Sent:* 24. maj 2013 13:42 *To:* Liubing
 > (Leo) *Cc:* [email-masked];
 > [email-masked] *Subject:*
 > Re: [v6ops] A brief intro-//RE: new draft:
 > which doesn't need much code to support address assignment mechanisms
 > like DHCP or ND." I don't think this makes sense. Are you saying such
 > nodes only support manual address assignment? How is it possible that
 > a sensor doesn't support automatic address assignment due to lack of
 > resources, but has enough resources to implement a UI for manual
 > address assignment?
 >
 > environment, there might not be a comprehensive network provisioning
 > environment for the nodes. If they can be pre-configured with ULA,
 > say, hard-coded in the embedded system, like the MAC addresses in
 > every single NIC or self-generating a ULA, then they could make
 > How are those nodes going to find the MAC address of the link router
 > to communicate off-link? If they can't do this, then you don't need
 > ULA, you can just use link-local. If they can do this, then they must
 > support router advertisements or similar. If they support router
 > [Bing] Surely they need to support SLAAC, it’s a basic IPv6 function
 > , the draft specifically noted this point. But if the sensors are in
 > a MANET, then the autoconfiguration is different with the traditional
 > wired SLAAC, since MANET is based on a multi hop topology. ULA is
 > suitable for this scenario, however, current text seems not
 > sufficient/clear, will modify later.
 >
 >
 >
 > some mechanism (e.g., RA) in order to find out who you can
 > <mailto:[email-masked]>] *Sent:* Friday, May 24, 2013 5:44 PM
 >
 >
 > *To:* Liubing (Leo) *Cc:* [email-masked] <mailto:[email-masked]>;
 > section 3.2.3. If I'm reading that section correctly, if you generate
 > 10000 ULAs you'll get a collision 1 in 500k times. If you generate
 > 100000 (e.g., if you regenerate them once a second, for one day)
 > you'll get a collision once in 1000 times. And so on.
 >
 > [Bing] In theory, I agree with you. But the point here is where do we
 > need to change the ULA so frequently? For random draw? I can hardly
 > imagine a use case of that.
 >
 >
 >
 > which doesn't need much code to support address assignment mechanisms
 > like DHCP or ND." I don't think this makes sense. Are you saying such
 > nodes only support manual address assignment? How is it possible that
 > a sensor doesn't support automatic address assignment due to lack of
 > resources, but has enough resources to implement a UI for manual
 > address assignment?
 >
 > environment, there might not be a comprehensive network provisioning
 > environment for the nodes. If they can be pre-configured with ULA,
 > say, hard-coded in the embedded system, like the MAC addresses in
 > every single NIC or self-generating a ULA, then they could make
 > How are those nodes going to find the MAC address of the link router
 > to communicate off-link? If they can't do this, then you don't need
 > ULA, you can just use link-local. If they can do this, then they must
 > support router advertisements or similar. If they support router
 > [Bing] Surely they need to support SLAAC, it’s a basic IPv6 function
 > , the draft specifically noted this point. But if the sensors are in
 > a MANET, then the autoconfiguration is different with the traditional
 > wired SLAAC, since MANET is based on a multi hop topology. ULA is
 > suitable for this scenario, however, current text seems not
 > sufficient/clear, will modify later.
 >
 >
 >
 > terrible operational complexity. But it is not a ULA-specific
 > problem; the multiple- addresses-per-interface is an important
 > feature of IPv6 protocol. Running multiple prefixes in IPv6 might be
 > very common, and we need to adapt this new operational model than
 > that in IPv4." This text does not make sense. Just because having
 > multiple global-scope addresses is a feature of IPv6 doesn't mean
 > that you must have multiple global-scope addresses. For example, you
 > can use only global addresses and have no routing complexity.
 >
 > prefixes in a network is new to the traditional IPv4 model, the
 > admins need to be familiar with it in the future.
 >
 > things being equal, having only one prefix (e.g., a global prefix) is
 > always going to be simpler than having two.
 >
 >
 >
 > because admins will need to understand the complexity anyway". What
 > I'm saying is that while they need to understand the complexity, we
 > don't have to create the complexity if we don't need it.
 >
 > [Bing] No, I’m not say that. ULA+PA is identified as beneficial use
 > case in 6renum and Homenet. So the admins need to adapt the

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 25 May 2013 10:48:29 +1200

On 25/05/2013 10:09, joel jaeggli wrote:
...
> will accommodate that without configuration change.

Well, I dunno. I am currently living in someone else's house for
a few weeks, and only yesterday, I had to reboot the ADSL box,
after which I could no longer print. Guess what? The printer's
IPv4 address had changed. Since the Bonjour mechanism provided
for the printer had already collapsed a couple of days earlier,
the fix was to log into the ADSL box, force DHCP to give the
previous IPv4 address to the printer's MAC address, and reboot
everything again.

Of course I'd love to get away from that, but I suspect that
the ability to force the printer address to <ULA_prefix>::6
instead of 192.168.1.6 would have been handy if this house
had IPv6.

    Brian

---

From: joel jaeggli <[email-masked]>
Date: Fri, 24 May 2013 16:03:42 -0700

On 5/24/13 3:48 PM, Brian E Carpenter wrote:
> Of course I'd love to get away from that,
I'd love to get away from non-working devices too... but the printer 
didn't have a static address assignment until you programmed the dhcp 
server. and if you connect it to a different network it will get a new 
address (which it will helpfully share).
>   but I suspect that
And then you'll change out the adsl modem. the next one, will assuming 
it assigns itself a ula pick a different one, and the printer will 
either have two or more ips,forget about the old one, be more 
conveniently addressed using link-local (different dicussion) or stop 
being accessible because it's only on the old subnet for which there's 
no RA and which your laptop will never discover.

the consumer is going to push the reset button or cycle the power when 
it doesn't work, and things are going to have sort themselves out.

---

From: Doug Barton <[email-masked]>
Date: Fri, 24 May 2013 20:16:51 -0700

On 05/24/2013 02:52 AM, Lorenzo Colitti wrote:
> On Wed, May 22, 2013 at 5:21 AM, Brian E Carpenter
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> Actually, I think the underlying problem as regards this specific draft
> is that ULAs were not well thought-out. They came out of a compromise
> where no side got what it wanted and what we got was a
> poorly-understood, possibly unusable hybrid.

Or, ULAs are just fine for their intended purpose, it's just that you 
don't like the purpose. :)

---

From: "Liubing (Leo)" <[email-masked]>
Date: Sat, 25 May 2013 06:16:16 +0000

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Friday, May 24, 2013 7:42 PM
To: Liubing (Leo)
Cc: [email-masked]; [email-masked]
Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations

 [Bing] The flaw is mainly regarding with your argument that if we can make autoconfiguration then we can make global prefix. As said in last mail, I don't think autoconfiguration necessarily means global provisioning, they are two perspectives.
Another point I want to argue is, not only simplify the nodes themselves, but also simplify the network provisioning/management. As discussed below, MANET currently could not do well with SLAAC.
But anyway, I think the current texts need to be updated to be more sufficient and accurate. Thanks.
And in MANET, the SLAAC is not (fully)applicable, see http://tools.ietf.org/html/draft-ietf-autoconf-statement-04.html#section-5.2

That draft expired in 2008, so it's not really relevant. Do you have a more up-to-date document?
 [Bing] Sorry, I haven't be aware of a more up-to-date document. But I think the issue is still valid.
B.R.
Bing
On Fri, May 24, 2013 at 8:01 PM, Liubing (Leo) <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Lorenzo

To: Liubing (Leo)

B.R.
Bing

---

From: Sander Steffann <[email-masked]>
Date: Sat, 25 May 2013 13:28:46 +0200

Hi,

> An autoconfiguration feature is a functionality, and compares badly to whatever static preconfiguration, in terms of memory/cpu constraints.
> 

I think what everybody is trying to tell you is that using a networking protocol only works if you follow the protocol's rules. IPv6 networks are divided into subnets, usually a /64 net network. Devices on the network need to know (a) which network they are on (prefix) and (b) what the gateway to other networks is. Depending on the setup and additional rules defined by the environment you might be able to hard-code (b).

Hard-coding (a) is the problem that everybody is pointing at: there will be >1 networks so you don't know up front which network the device will be connected to. Now you can pretend that there is only 1 network and hard-code all addresses from the same /64 prefix (ULA or global, doesn't matter, it's just a number) but then devices from other networks will have no way of communicating with them (because the rest of the world can't distinguish between the different instances of that 'one' network). This is scenario 1 that Owen described: "Multiple devices with the same prefix not on the same network". You might as well use link-local addresses in that case... If you use multiple /64s then you run into scenario 2: "Multiple devices with different prefixes unable to recognize each other on the same network".

The problem is not in which set of addresses you use but the fact that your device will be less flexible in its behaviour than the environment it is supposed to work in. It won't adapt to its environment and will not work properly.

The only thing you might do is to let the users 'burn in' the addresses themselves when installing the device. The user is then responsible for adapting the device to the environment (network) it is going to be used on. I just don't see why you would want to force such an user-unfriendly and error-prone task task on the user/installer when with a tiny bit of extra code you could make the device auto-configure itself by listening to Router Advertisements...

Cheers,
Sander

---

From: Owen DeLong <[email-masked]>
Date: Sat, 25 May 2013 18:53:32 -0700

> But sure a device which has its address pre-configured could go very far in reducing its memory/cpu print.
> 

You can go even further if you take out the IP stack altogether. At some point, there's diminishing returns.

Failure to support RA and SLAAC at a minimum is, IMHO, below that threshold.

>>> change since the
> Its sufficient for the remote apps to be preconfigured with the devices' addresses, no need to preconfigure the other way around.

How does one reach the other? How do these preconfigured addresses find each other?

If you're proposing building in a limitation that they all have to be on the same link, then there's no reason to use ULA, you can just use link local.

If not, you have some 'splaining to do in answering the above question.

> And there are other simpler ways.

Such as? Note, ways which require all devices to be on the same link are not a valid answer as such ways do not need ULA and can use LL instead.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Sat, 25 May 2013 18:58:03 -0700

On May 24, 2013, at 20:16 , Doug Barton <[email-masked]> wrote:

> Or, ULAs are just fine for their intended purpose, it's just that you don't like the purpose. :)

I'm still waiting for someone to clearly state what that purpose is.

Owen

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 26 May 2013 14:48:58 +1200

> I'm still waiting for someone to clearly state what that purpose is.

I really don't see what's wrong with the Abstract of RFC 4193.

If you don't see a need personally or for your customers, that's
fine. All the IETF does is provide mechanisms; users decide which
ones to use.

    Brian

---

From: Owen DeLong <[email-masked]>
Date: Sat, 25 May 2013 22:37:07 -0700

> I really don't see what's wrong with the Abstract of RFC 4193.

The abstract is fine. However, it doesn't answer the question asked. The abstract does a great job of describing what ULA does.

It does nothing to explain what problem that solves or what purpose it serves in doing so.

> fine. All the IETF does is provide mechanisms; users decide which

Ideally, it would be nice if the IETF focused on mechanisms that had a real world purpose. Solutions looking for a problem tend to create more problems than they solve. In many ways, ULA seems to fit that definition.

Owen

---

From: Mark Andrews <[email-masked]>
Date: Mon, 27 May 2013 08:08:44 +1000

> Ideally, it would be nice if the IETF focused on mechanisms that had a real world purpose. Solutions
>  looking for a problem tend to create more problems than they solve. In many ways, ULA seems to fit 
> that definition.
> 
> Owen

Owen, there is no perfect solution to numbering residential networks.

* getting addresses from a RIR works worse than ULA as you can't get
  them routed and RIR address are not in a well defined range.

* getting addresses from a ISP doesn't work as you need addresses
  before your initial connection.  Additionally they require
  full renumbering when switching providers or when the ISP decides
  to rejig their address plan.

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

---

From: Gert Doering <[email-masked]>
Date: Mon, 27 May 2013 12:24:50 +0200

Hi,

>   to rejig their address plan.

Maybe it really should be stated twice per mail that this is talking
about "large scale residentical ISPs"

I can already see Owen speak up "of course my ISP is routing my IPv6 PI
space".  Yes, some will, and will take extra money for it (and that is
all fine), but the vast majority of users will not go there.

Gert Doering
        -- NetMaster

---

From: joel jaeggli <[email-masked]>
Date: Mon, 27 May 2013 07:57:09 -0700

> I really dont see why arguing against this, it's simply basics.
A dynamically configured system may be dramatically less costly to setup 
and intergrate. it may be signficantly less brittle in the face of 
change and fail (on in fact not fail) a lot more gracefully.

A statically configured system still has to employ NDP and unless you 
want really ugly failures in the face of misconfiguration, guard against 
duplicates so the dynamic code path remains.

it is being discussed because you bring up the question the context of 
ula usage recommendations draft.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 28 May 2013 00:45:36 +0900

> don't like the purpose. :)

I don't feed trolls unless they tell me what to eat :-)

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 28 May 2013 00:47:58 +0900

>   them routed and RIR address are not in a well defined range.

You can't get ULAs routed either.

>   to rejig their address plan.

Agreed, ULA gives you stable addresses for a disconnected network.

---

From: Owen DeLong <[email-masked]>
Date: Mon, 27 May 2013 10:14:00 -0700

>  them routed and RIR address are not in a well defined range.

False... http://www.tunnelbroker.net Q.E.D.

>  to rejig their address plan.

Arguable, but not completely unreasonable. Though I question what value these unroutable addresses provide that are not available from RIR addresses which you may be unable to route.

Owen

---

From: Mark Andrews <[email-masked]>
Date: Tue, 28 May 2013 09:07:40 +1000

In message <[email-masked]>, Owen DeLong write
> False... http://www.tunnelbroker.net Q.E.D.

And the number of untunneled residential customers HE have is what now?

> Arguable, but not completely unreasonable. Though I question what value
> these unroutable addresses provide that are not available from RIR
> addresses which you may be unable to route.
>
> Owen

Owen go and try and bring up a new IPv6 only home network with two
broadcast domains with no current external connectivity and see how
far you get.  Printer in one broadcast domain and a PC in the other.
Now try to print a test page from that PC.  This isn't (or won't
be) a uncommon senario.  This is what we are designing to support.

Mark

---

From: Sander Steffann <[email-masked]>
Date: Tue, 28 May 2013 01:18:07 +0200

Hi Mark,

> go and try and bring up a new IPv6 only home network with two

+1
Sander

---

From: Mark Andrews <[email-masked]>
Date: Tue, 28 May 2013 09:59:50 +1000

In message <CAKD1Yr0rXCgO=[email-masked]>

> You can't get ULAs routed either.

I didn't say you could.

ULA however are better than a generic prefix from a RIR in that the
software knows (or will know) that they are not globally routable
and can make sensible default decisions when presented with a mixture
of ULA and GUA addresses.

The alternative to ULA + GUA is non-routed GUA + PA GUA and unless
the home network is pushing around address selection tables there is
nothing to tell the two addresses apart.  This will lead to the wrong
source address being choosen.

---

From: Owen DeLong <[email-masked]>
Date: Tue, 28 May 2013 11:41:18 -0700

> of ULA and GUA addresses.

Maybe, maybe not.

Dual GUA with RIOs to aid local traffic SAS could be just as effective as
GUA+ULA.

> source address being chosen.

Agreed. Where we disagree is in that you seem to expect that SAS will actually
end up working correctly on at least a semi-consistent basis in the ULA+GUA
scenario. Of that, I remain very skeptical.

Owen