Subject: [v6ops] NPT66 comment on draft-ietf-v6ops-ula-usage-recommendations

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 6 Mar 2014 14:16:12 +0000

Section 3.2.1 says;

   In some very constrained situations(for example, in the sensors), 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 full
ND (Note: surely it needs SLAAC). If the network also   needs to connect to
the outside, then there can be an NPTv6 gateway   which is not subject to
extreme resource constraints. Especially when   a lightweight isolated
network needs to add Internet connectivity,   this is quite a
straightforward and efficient way.

It's not clear what constraints are referred to here. If the sensor nodes
already support SLAAC, then why can't they support ULA+GUA as documented in
section 3.2.2?

Is this something we want to recommend?

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 06 Mar 2014 15:48:53 +0100

Le 06/03/2014 15:16, Lorenzo Colitti a écrit :
> network needs ULA as the on-demand and stable addressing which
> doesn't need much code to support address assignment mechanisms like
>  DHCP or full ND (Note: surely it needs SLAAC). If the network also
>  needs to connect to the outside, then there can be an NPTv6 gateway
>  which is not subject to extreme resource constraints. Especially
> when a lightweight isolated network needs to add Internet
> connectivity, this is quite a straightforward and efficient way.
>
> It's not clear what constraints are referred to here.

I guess it is sensor constraints, not NPT-box constraints.

> If the sensor nodes already support SLAAC, then why can't they
> support ULA+GUA as documented in section 3.2.2?
>

I dont think it recommends, I think it observes, or it considers it a
'quite' straightforward way.  Should it say MAY instead?  Or 'attractive
way'?

Or should it add something else that NPT? (i.e. NAT).

Alex

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

---

From: Ray Hunter <[email-masked]>
Date: Thu, 06 Mar 2014 18:17:27 +0100

> I guess it is sensor constraints, not NPT-box constraints.
How names spaces? It's a can of worms for nodes that move across the 
prefix translation boundary.
>> Is this something we want to recommend?
Not IMHO. Any sort of translation starts making name spaces and caching 
on highly mobile nodes much tougher than it needs to be.

It may be easier for the individual sensors, but it makes the overall 
Internet a poorer place.

If there needs to be any gateway due to resource constraints, it should 
be an ALG placed between the sensor segment and the rest of the Internet 
IMVHO.

-- 
Regards,
RayH

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 6 Mar 2014 17:22:07 -0800 (PST)

>________________________________
> From: Lorenzo Colitti <[email-masked]>
>To: "[email-masked] WG" <[email-masked]> 
>Sent: Friday, 7 March 2014 1:16 AM
>Subject: [v6ops] NPT66 comment on draft-ietf-v6ops-ula-usage-recommendations
> 
>
>
>Section 3.2.1 says;
>
>   In some very constrained situations(for example, in the sensors), 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 full ND (Note: surely it needs SLAAC). If the network also   needs to connect to the outside, then there can be an NPTv6 gateway   which is not subject to extreme resource constraints. Especially when   a lightweight isolated network needs to add Internet connectivity,   this is quite a straightforward and efficient way.
>
>
>It's not clear what constraints are referred to here. If the sensor nodes already support SLAAC, then why can't they support ULA+GUA as documented in section 3.2.2?
>
>

I don't think it is. If a node is so resource constrained that it can't support 3 IPv6 prefixes instead of two (i.e., LL + ULA vs LL + ULA + GUA), then I'd wonder if it has enough resources to to run even a basic application usefully.

If it can't support 3 IPv6 prefixes, perhaps the node shouldn't be a general purpose computer that supports running applications locally at all, but should instead be an input or output device of some form that is attached via something much simpler than IPv6 to a computer that does run the applications and does run IPv6 well enough.

Regards,
Mark.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 07 Mar 2014 08:30:26 +0100

Le 07/03/2014 02:22, Mark ZZZ Smith a écrit :
>
>
>
>
>
>> ________________________________ From: Lorenzo Colitti
>> <[email-masked]> To: "[email-masked] WG" <[email-masked]> Sent:
>> Friday, 7 March 2014 1:16 AM Subject: [v6ops] NPT66 comment on
>> draft-ietf-v6ops-ula-usage-recommendations
>>
>>
>>
>> Section 3.2.1 says;
>>
>> In some very constrained situations(for example, in the sensors),
>> 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 full ND (Note: surely it needs SLAAC). If
>> the network also   needs to connect to the outside, then there can
>> be an NPTv6 gateway   which is not subject to extreme resource
>> constraints. Especially when   a lightweight isolated network needs
>> to add Internet connectivity,   this is quite a straightforward and
>> efficient way.
>>
>>
>> It's not clear what constraints are referred to here. If the sensor
>> nodes already support SLAAC, then why can't they support ULA+GUA as
>> documented in section 3.2.2?
>>
>>
> I don't think it is. If a node is so resource constrained that it
> can't support 3 IPv6 prefixes instead of two (i.e., LL + ULA vs LL +
>  ULA + GUA), then I'd wonder if it has enough resources to to run
> even a basic application usefully.
>
> If it can't support 3 IPv6 prefixes, perhaps the node shouldn't be a
>  general purpose computer that supports running applications locally
>  at all, but should instead be an input or output device of some form
>  that is attached via something much simpler than IPv6 to a computer
>  that does run the applications and does run IPv6 well enough.

In this direction, a possibility may be to make IPv6 adapt to the
simplest applications on such nodes: maybe only use one address
(presumably ULA or GUA, but not LL), maybe lower the RFC2460 minimal MTU
to 41bytes (full base header and 1 byte of app), maybe run only one
autoconfig protocol (not both RA+DHCP and that link layer's autoconfig),
and so on.

I think the use of ULAs is not preventing any of these, and is not
necessarily inviting the use of NPT - it could work with it, or not.

But, if asked whether preferring a ULA address on the sensor, or just
that link layer's address, I'd prefer the former, because it has larger
scope, could be reached from more places.

Alex

> Regards, Mark.

---

From: Owen DeLong <[email-masked]>
Date: Fri, 7 Mar 2014 00:47:38 -0800

> It's not clear what constraints are referred to here. If the sensor nodes already support SLAAC, then why can't they support ULA+GUA as documented in section 3.2.2?

+1

> Is this something we want to recommend?

No, it is something we should recommend against.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Fri, 7 Mar 2014 00:52:56 -0800

On Mar 6, 2014, at 6:48 AM, Alexandru Petrescu <[email-masked]> wrote:

> way’?

1.	I don’t understand how this is “quite straightforward”. It has all the problems and complications of NAT, where as the ULA+GUA outlined in 3.2.2 is, in fact, quite straightforward.

2.	Calling it “quite straightforward” is, in essentially an endorsement in the English vernacular.

3.	I don’t think changing to MAY helps.

4.	Calling it “attractive way” is going in the wrong direction.

In short, I see little need for this scenario other than perhaps documenting it as a less preferred alternative than 3.2.2 and documenting the reasons for said preference.

Owen

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

---

From: Owen DeLong <[email-masked]>
Date: Fri, 7 Mar 2014 01:24:18 -0800

> If it can't support 3 IPv6 prefixes, perhaps the node shouldn't be a general purpose computer that supports running applications locally at all, but should instead be an input or output device of s…

There’s a lot of room between “so constrained it can’t handle 3 prefixes” and “a general purpose computer that supports running applications locally”.

The latter is not a requirement for an IPv6 node, nor should it be. However, with current technology, even the smallest and simplest of sensors that have enough hardware to be on a network directly ought to be able to handle 3 prefixes. Indeed, perhaps we should determine some minimum number of IPv6 prefixes and some minimum number of addresses that we think a minimalist node should be capable of supporting and document that in an RFC. (not applicable to this draft, but perhaps worthy of a new draft).

Owen

---

From: Owen DeLong <[email-masked]>
Date: Fri, 7 Mar 2014 01:37:03 -0800

> autoconfig protocol (not both RA+DHCP and that link layer's autoconfig),

This makes no sense… Too many things depend on LL and eliminating it
would be a pretty fundamental redesign of the protocol functionality.

I don’t think we need to redesign the protocol for small nodes. The reality is
that nobody has yet claimed an actual node that can’t handle a third prefix,
there is merely some level of speculation that such a node might exist.

It is expected that most constrained nodes will run ND/SLAAC only and will not support
DHCPv6. (such nodes aren’t likely to be routers, so they should not be sending
RAs).

> necessarily inviting the use of NPT - it could work with it, or not.

I think documenting a case of ULA+NPT as a recommended or straight-forward
way of doing things is ill-advised. ULA without NPT for local connectivity is tolerable.
ULA+GUA for stable local connectivity with transient global connectivity is tolerable.
Persistent GUA is better for the vast majority of applications.

ULA+NPT is simply a really bad idea in virtually any context.

> scope, could be reached from more places.

I don’t think this is a question of either/or and I think you are conflating several
issues that aren’t part of this thread and perhaps not really related to this
document into the discussion.

Owen

---

From: "Brzozowski, John" <[email-masked]>
Date: Fri, 7 Mar 2014 18:51:47 +0000

The following question from Lorenzo seems valid.  In the thread thus far I
have not seen a reply.  Can the authors please comment on the below?

"It's not clear what constraints are referred to here. If the sensor nodes
already support SLAAC, then why can't they support ULA+GUA as documented
in section 3.2.2?"

John

=========================================
John Jason Brzozowski
Comcast Cable
m) 609-377-6594
o) 484-962-0060
w) www.comcast6.net
e) [email-masked]
=========================================

-----Original Message-----
From: Alexandru Petrescu <[email-masked]>
Date: Friday, March 7, 2014 7:30 AM
To: Mark ZZZ Smith <[email-masked]>, Lorenzo Colitti
<[email-masked]>, v6ops <[email-masked]>
Subject: Re: [v6ops] NPT66 comment on
draft-ietf-v6ops-ula-usage-recommendations

---

From: "Brzozowski, John" <[email-masked]>
Date: Sat, 8 Mar 2014 01:03:26 +0000

-----Original Message-----
From: Owen DeLong <[email-masked]>
Date: Friday, March 7, 2014 9:37 AM
To: Alexandru Petrescu <[email-masked]>
Cc: v6ops <[email-masked]>
Subject: Re: [v6ops] NPT66 comment on

>would be a pretty fundamental redesign of the protocol functionality.
[jjmb] I agree with this statement, an alteration like this would be
significant.

>there is merely some level of speculation that such a node might exist.
[jjmb] +1

>DHCPv6. (such nodes aren’t likely to be routers, so they should not be
[jjmb] this has been our experience.

---

From: Tim Chown <[email-masked]>
Date: Sat, 8 Mar 2014 22:44:34 +0000

> I guess it is sensor constraints, not NPT-box constraints.

By “guess”, do you mean you are reporting something you know first hand here, or something you think might apply?

In homenet-arch, we explictly say "neither IPv6 NAT or NPTv6 is recommended for use in the homenet architecture”, despite ULAs being noted; it’s assumed that an IPv6 node communicating externally will have a GUA as well. The text also meantions that some devices, which may include constrained devices, *might* only have a ULA, but hat would imply internal-only communication. It may be good to clarify this in the homenet text.

Tim

---

From: Mark ZZZ Smith <[email-masked]>
Date: Sat, 8 Mar 2014 15:38:48 -0800 (PST)

----- Original Message -----
> Cc: Mark ZZZ Smith <[email-masked]>; Lorenzo Colitti <[email-masked]>; "[email-masked] WG" <[email-masked]>
> Sent: Friday, 7 March 2014 8:37 PM
> Subject: Re: [v6ops] NPT66 comment on draft-ietf-v6ops-ula-usage-recommendations
> 
> 
  
<snip>

+1

I think the real value of LLs is, as per the IPv6 addressing architecture, that all IPv6 interfaces are required to have Link-Local addresses (RFC4291, 2.8). That means they're guaranteed to always available, and should be used within a link whenever possible, including for applications, because they'll be the most reliable addresses to use, as they'll never go away by themselves (i.e., expire through aging). This is why they're supported for applications in RFC4007, and are preferred over greater scope addresses in RFC6724.

While routers announcing ULA or GUA prefixes are going to be common, but I don't think should be necessary to have a router on a link to just communicate between two directly attached hosts over IPv6. 

It seems that they're viewed by some people as unnecessary and unuseful, just because the equivalent didn't really exist in IPv4. They are not a new idea, at least IPX and Appletalk also had "this network" prefixes. They were also somewhat retrofitted into IPv4 via 169.254/16, so I think that shows that the idea of an "always there" prefix has been useful in a number of scenarios.

<snip>

Regards,
Mark.

---

From: Tim Chown <[email-masked]>
Date: Sat, 8 Mar 2014 23:54:17 +0000

>> Subject: Re: [v6ops] NPT66 comment on draft-ietf-v6ops-ula-usage-recommendations
…….
> While routers announcing ULA or GUA prefixes are going to be common, but I don't think should be necessary to have a router on a link to just communicate between two directly attached hosts over IP…

Absolutely. And various zeroconf protocols are designed to work in such environments using LLs.

> It seems that they're viewed by some people as unnecessary and unuseful, just because the equivalent didn't really exist in IPv4. They are not a new idea, at least IPX and Appletalk also had "this…

I agree, and I recal 169.254 was added for zeroconf, but we’re now getting off topic a bit :)

Tim

---

From: Owen DeLong <[email-masked]>
Date: Sun, 9 Mar 2014 07:50:15 -0700

> In homenet-arch, we explictly say "neither IPv6 NAT or NPTv6 is recommended for use in the homenet architecture”, despite ULAs being noted; it’s assumed that an IPv6 node communicating externally w…

I think the home net text has it right. I do not think that recommending NPTv6 is a good idea.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Sun, 9 Mar 2014 08:17:53 -0700

> It seems that they're viewed by some people as unnecessary and unuseful, just because the equivalent didn't really exist in IPv4. They are not a new idea, at least IPX and Appletalk also had "this…

There is a valid argument to be made that in IPv4, they did more harm than good due to issues with the way they were cobbled into IPv4. Those issues, while not present in IPv6, may taint people’s perspectives about them.

Owen

---

From: joel jaeggli <[email-masked]>
Date: Sun, 09 Mar 2014 17:06:25 +0000

On 3/9/14, 3:17 PM, Owen DeLong wrote:
>> It seems that they're viewed by some people as unnecessary and
>> unuseful, just because the equivalent didn't really exist in IPv4.
>> They are not a new idea, at least IPX and Appletalk also had "this
>> network" prefixes. They were also somewhat retrofitted into IPv4
>> via 169.254/16, so I think that shows that the idea of an "always
>> there" prefix has been useful in a number of scenarios.
> 
> There is a valid argument to be made that in IPv4, they did more harm
> than good due to issues with the way they were cobbled into IPv4.
> Those issues, while not present in IPv6, may taint people’s
> perspectives about them.

no residential provider I've ever had from 1992 to present has ever
delegated a v4 prefix large enough to number everything in my house let
alone (in more recent times behind my phone.

v4 link-local works after a fashion it's always been synonymous with
either broken, or adhoc networking which is dandy until you put a router
on the subnet.

---

From: Tim Chown <[email-masked]>
Date: Sun, 9 Mar 2014 19:11:52 +0000

> alone (in more recent times behind my phone.

Ironically the most well-known native IPv6 ISP in the UK also (until recently I believe) gave a /28 IPv4 prefix for residential customers. I don’t know where your house is though on the scale of "typical home network" to "House Arkko"...

> either broken, or adhoc networking which is dandy until you put a router

Well, I’ve always thought of IPv4 LL as being intended for non-connected networks, with devices only having the LL. As you say though it’s probably most often seen due to broken IPv4 DHCP. A key difference with v6 is you have both LL and global. 

Tim

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 10 Mar 2014 18:46:09 +0100

Le 07/03/2014 10:37, Owen DeLong a écrit :
>>>> <[email-masked]> To: "[email-masked] WG" <[email-masked]>
>>>> Sent: Friday, 7 March 2014 1:16 AM Subject: [v6ops] NPT66
>>>> comment on draft-ietf-v6ops-ula-usage-recommendations
>>>>
>>>>
>>>>
>>>> Section 3.2.1 says;
>>>>
>>>> In some very constrained situations(for example, in the
>>>> sensors), 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 full ND (Note: surely it
>>>> needs SLAAC). If the network also   needs to connect to the
>>>> outside, then there can be an NPTv6 gateway   which is not
>>>> subject to extreme resource constraints. Especially when   a
>>>> lightweight isolated network needs to add Internet
>>>> It's not clear what constraints are referred to here. If the
>>>> sensor nodes already support SLAAC, then why can't they
>>> can't support 3 IPv6 prefixes instead of two (i.e., LL + ULA vs
>>> LL + ULA + GUA), then I'd wonder if it has enough resources to to
>>> run even a basic application usefully.
>>>
>>> If it can't support 3 IPv6 prefixes, perhaps the node shouldn't
>>> be a general purpose computer that supports running applications
>>> locally at all, but should instead be an input or output device
>>> of some form that is attached via something much simpler than
>>> IPv6 to a computer that does run the applications and does run
>>> IPv6 well enough.
>>
>> (presumably ULA or GUA, but not LL), maybe lower the RFC2460
>> minimal MTU to 41bytes (full base header and 1 byte of app), maybe
>> run only one autoconfig protocol (not both RA+DHCP and that link
>> layer's autoconfig), and so on.
>

Whereas I agree with the necessity of LL in other contexts where it is
currently overlooked, I think much of the LL need is from ND, MLD an
DHCP.  I think none of them is mandatory by specification (i.e. no spec
requires a node to implement e.g. ND).

It must not be because of too heavy protocol functionality that the
simplest of the nodes do not respond to ping6.  Ping6 is a very simple
functionality whose most complex requirement is in the checksum
calculation, that's all.

And, given a choice between LL and other scope address, one would prefer 
other scope address because it is inevitably larger.

> I don’t think we need to redesign the protocol for small nodes.

I fully agree.  I do not talk of redesign of new protocol, but eliminate
the parts which are in the way.  It's like when running IP over SLIP.

> The reality is that nobody has yet claimed an actual node that can’t
> handle a third prefix, there is merely some level of speculation
> that such a node might exist.

Right.

There are very many Bluetooth nodes out there which are very powerful
and dont have IP on them at all.

But there are many other nodes out there on which nobody puts IP because
they think IP is too heavy.

This is again a matter of formulation and people should understand it.

There are differences between saying that a constrained node can accept
a GUA, a ULA, or can run with both, and that it is unacceptable to say 
that because GUA works ULA is not needed.

> It is expected that most constrained nodes will run ND/SLAAC only
> and will not support DHCPv6. (such nodes aren’t likely to be routers,
> so they should not be sending RAs).

I beg to differ.  Many if not most of these nodes in sensor networks are 
supposed to be actually routers.

> I think documenting a case of ULA+NPT as a recommended or
> straight-forward way of doing things is ill-advised. ULA without NPT
> for local connectivity is tolerable.

Yes, but not the 'ill' part.  Maybe just advised in some context not others.

> majority of applications.

I am not sure this is as clear as you writ eit.  I just dont see any 
mentioning of Mobile IP or route updates, which are quintessential to 
realize what you say.

> ULA+NPT is simply a really bad idea in virtually any context.

Disagree.  It is a good idea in many contexts at the edge.

It is a good idea for the smartphone-and-single-subnet use-case (like in 
tethering, mobile hotspot).  But it is inadequate for a vehicle where 
are several subnets and still a single /64 is given to it.

>> But, if asked whether preferring a ULA address on the sensor, or
>> just that link layer's address, I'd prefer the former, because it
>> has larger scope, could be reached from more places.
>
> I don’t think this is a question of either/or and I think you are
> conflating several issues that aren’t part of this thread and
> perhaps not really related to this document into the discussion.

I agree.

It is not me who conflates.

You got here NPT mixed in, and simultaneous or alternative uses of ULA/GUA.

I could add many more if I wanted (NAT, Mobile IP, DHCP PD, 64share, 
route updates) but I restrain for the benefit of focusing.

In all cases, it is unacceptable to not recommend ULA in certain 
contexts, mostly at the edge.

People who think core networks have different perspectives than people 
who think networks at the far edge, like the network of sensors you 
build on a table disconnected from anything else at the first time.  Try 
to build one, and picture is clearer.  What prefix to put on these 
sensors?  Ask the admin.  The admin says some prefix  but _only_ if 
connected at point X, otherwise dont put that GUA.  Mobile IP?  Too 
heavy at this time, just I need some address to put there.  This is the 
essence of ULA reasoning.

Alex

---

From: Owen DeLong <[email-masked]>
Date: Mon, 10 Mar 2014 12:06:14 -0700

> requires a node to implement e.g. ND).

I don't think that ND is optional, but I could be wrong. How would you expect
a node that is not on a point-to-point link to function without ND?

LL is also required for DAD, OSPF, and many other processes. Much of IPv6
assumes that if an interface does not have an LL address, it is not running IPv6.

> And, given a choice between LL and other scope address, one would prefer other scope address because it is inevitably larger.

I no of no IPv6 implementation where a node can support only a single address. I do not believe any conforming implementation can limit an interface to a single address, though I believe there is no specified minimum number of addresses supported.

> the parts which are in the way.  It's like when running IP over SLIP.

I do not for one second believe that LL or multiple address requirements are in the way. Do you have an example of an actual implementation where this is an issue? So far, all we've heard is speculation about "constrained nodes" that "might exist" which "might have a problem with 2 or more global scoped addresses at the same time".

Absent evidence that such an issue really exists in the real world, I am very hesitant to go through any of the gyrations you have suggested as I believe they would be more harmful than useful.

> a GUA, a ULA, or can run with both, and that it is unacceptable to say that because GUA works ULA is not needed.

I'm quite certain that I do not understand your point here.

> I beg to differ.  Many if not most of these nodes in sensor networks are supposed to be actually routers.

A node which is supposed to be a router should not be so resource constrained. Building a router which is so resource constrained as to be unable to handle multiple addresses on one of its interfaces is absurd as you will need much more resources than what would support that requirement to support other things in the router like the neighbor table, timer tables, routing tables, etc.

> Yes, but not the 'ill' part.  Maybe just advised in some context not others.

No, it is utterly and completely ill-advised in any context.

It is not straight forward. It is harmful. If you need global reachability, you should be using GUA on the node. Silly NPT games degrade service in all cases where they are applied.

NPT may be convenient for some operators in some contexts for some amount of time, but in all such cases, they produce corresponding harm and come at a price which may not be paid by the implementer. (c.f. toxic polluter model)

> I am not sure this is as clear as you writ eit.  I just dont see any mentioning of Mobile IP or route updates, which are quintessential to realize what you say.

Mobile IP is all about preserving stable GUA on a host, so I'm not sure how you can say that what I have said above does not align completely with Mobile IP.

Route updates are, generally, about providing new information about how to reach GUA, so, again, I don't see how what I have proposed is not clearly aligned with that goal.

> Disagree.  It is a good idea in many contexts at the edge.

Name one.

> It is a good idea for the smartphone-and-single-subnet use-case (like in tethering, mobile hotspot).  But it is inadequate for a vehicle where are several subnets and still a single /64 is given to it.

No, it is not. It provides no benefit whatsoever vs. simply delivering GUA to the subnet instead.

> You got here NPT mixed in, and simultaneous or alternative uses of ULA/GUA.

That is the topic of the discussion from the beginning.

> I could add many more if I wanted (NAT, Mobile IP, DHCP PD, 64share, route updates) but I restrain for the benefit of focusing.
> 
> In all cases, it is unacceptable to not recommend ULA in certain contexts, mostly at the edge.

I'm not saying we can't recommend ULA in certain cases.

I am saying that recommending NPT or any other form of NAT should be avoided.

> People who think core networks have different perspectives than people who think networks at the far edge, like the network of sensors you build on a table disconnected from anything else at the first time.  Try to build one, and picture is clearer.  What prefix to put on these sensors?  Ask the admin.  The admin says some prefix  but _only_ if connected at point X, otherwise dont put that GUA.  Mobile IP?  Too heavy at this time, just I need some address to put there.  This is the essence of ULA reasoning.

I have built several. My picture is quite clear, I assure you. I have used ULA and/or LL for such networks. OTOH, when I connect those sensors to a larger network, I do NOT leave them with ULA or LL only. I add GUA and that makes things work. 

GUA for these sensors can be flash-renumbered very quickly without impact if the network is designed correctly. Having the GUA change when the connectivity changes is not a problem for such networks. They can preserve stable ULA in addition for functions where this is useful. I don't oppose that. What I do oppose is using NPT instead of delivering the GUA to the nodes in question. Doing so is absurd and harmful.

Owen

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 11 Mar 2014 03:37:16 +0000

Hi John & Lorenzo,

Sorry for the late reply.

The case is an assumption that handling multiple prefixes issues such as address selection might be too complex for a "constrained node". It is intended to be a hint that NPTv6 might be needed in some situation. However, constrained node maybe failed to be a good example of it.
But it is not intended to be any kind of Recommendation. If assumption is problematic to describe potential use cases, we'll consider to delete the relevant texts.

Best regards,
Bing

> From: v6ops [mailto:[email-masked]] On Behalf Of Brzozowski,
> John
> Sent: Saturday, March 08, 2014 2:52 AM
> To: Alexandru Petrescu; Mark ZZZ Smith; Lorenzo Colitti; [email-masked] WG
> already support SLAAC, then why can't they support ULA+GUA as
> documented in section 3.2.2?"
> 
> John
> 
> Sent:
> >> ULA + GUA), then I'd wonder if it has enough resources to to run even
> >> a basic application usefully.
> >>
> >(presumably ULA or GUA, but not LL), maybe lower the RFC2460 minimal
> >MTU to 41bytes (full base header and 1 byte of app), maybe run only one
> >autoconfig protocol (not both RA+DHCP and that link layer's
> >autoconfig), and so on.
> >

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 11 Mar 2014 13:43:01 +0900

On Tue, Mar 11, 2014 at 12:37 PM, Liubing (Leo) <[email-masked]>wrote:

> The case is an assumption that handling multiple prefixes issues such as
> address selection might be too complex for a "constrained node". It is
> intended to be a hint that NPTv6 might be needed in some situation.
> However, constrained node maybe failed to be a good example of it.
>

1. If it's not a good example, then we should delete it.
2. If it's the only example, then we should avoid listing ULA-only
deployment using NPTv6 as a scenario. The NPTv6 RFC says "the IETF does not
recommend the use of Network Address Translation technology for IPv6", so
we should not list this as a scenario unless there is a use case for it.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Mar 2014 21:25:57 +1300

> a node that is not on a point-to-point link to function without ND?

It's a SHOULD in fact:

http://tools.ietf.org/html/rfc6434#section-5.2

That means you need a very good technical reason not to implement it.
A pt2pt link might be such a reason.

...

> No, it is utterly and completely ill-advised in any context.

Agreed. There are sometimes claims that it is a security solution,
but a firewall is the lesser evil in that case.

...

On 11/03/2014 10:01, Owen DeLong wrote:
...
> My point is that we should avoid recommending ULA+NPT for hosts that are communicating to the outside world because NPT and all other forms of NAT should be considered harmful.

IMHO that is consistent with the NPTv6 experimental RFC document
(2nd para at http://tools.ietf.org/html/rfc6296#section-1).
Clearly the ULA document should say the same.

    Brian

---

From: Mark ZZZ Smith <[email-masked]>
Date: Fri, 14 Mar 2014 19:15:04 -0700 (PDT)

----- Original Message -----
> To: Owen DeLong <[email-masked]>
> Sent: Tuesday, 11 March 2014 4:46 AM
<snip>
> other scope address because it is inevitably larger.

I'm a bit confused by this. When it comes to using an address as a source or destination (both at the IPv6 layer or the application layer), when there is a a choice between two or more of a set of LLs, ULAs and GUAs, LLs are going to be potentially more reliable better than ULAs, which are going to be potentially more reliable than GUAs.

The greater the scope of the address, the more parties and devices involved in providing it, configuring it and operating it, which I think reduces its potential reliability and availability. As I don't think many applications are robust to addresses expiring or becoming unavailable through some network failure, the addresses to prefer are the ones that are least likely to be disrupted by external events and never expire. LLs, as a source or destination, if usable because the src/destination are on the same link, are going to be as reliable as the link itself, as they have infinite lifetimes, are required to be on all IPv6 interfaces, and don't require a router to be present to announce them. 

Regards,
Mark.