Subject: Re: [v6ops] ULA & Basic Requirements for IPv6 Customer Edge Routers

From: RJ Atkinson <[email-masked]>
Date: Wed, 8 Dec 2010 19:46:23 -0500

My perception is that the entire ULA topic is pretty contentious,
with some folks apparently desiring to mandate ULA support and 
other folks apparently wanting to prohibit ULA support.  This
list seems a bit polarised on this topic, which seems unfortunate.

I wonder whether WG consensus might be optimised by editing
this I-D along the lines of James Woodyatt's note dated
"Wed, 08 Dec 2010 15:24:40 -0800", BUT, importantly, 
*omitting* the last 3 "MUST NOT" items from Section 6 
of that same email.

The result of this would be to permit, but NOT require, 
routers covered by this I-D to include ULA support.

At some future point, for example in a world where folks
don't perceive ULA deployment as impeding user access
to otherwise public content on the Internet, more specific
recommendations about ULA support (or ULA non-support) 
might more easily reach consensus.

As Fred's note with date Wed, 8 Dec 2010 13:01:07 -0800
indicated (towards the end of that note), a non-trivial 
number of devices within the scope for this I-D will be 
deployed inside employee homes or as in small offices 
that are connected with (and often also managed by) larger 
"corporate" networks that have significant internal network 
structure.  

So this I-D does not appear to primarily be focused on 
"mass market" or "consumer electronics" home routers.  

(Some folks might wish the Introduction of this I-D made 
that distinction more crisply; other folks might think 
the distinction has already been made crisply enough. :-)

Anyway, food for thought.

Yours,

Ran

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 8 Dec 2010 19:28:24 -0600

A very fundamental nature of IPv6 is to support multiple IPv6 addresses
on a network interface.  Since the ULA has global scope, the ULA is just
like any other IPv6 global address provisioned on a network interface.
Thus we cannot back off from the ULA as James is asking of.  Any network
interface for IPv6 of an IPv6 node has got to implement the RFC 4193 ULA
prefix generation algorithm.  If the ULA prefix generation be turned off
for default is desired, I suppose we could discuss the default behavior.
That is the only issue at hand to resolve.  

Hemant 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of RJ Atkinson
Sent: Wednesday, December 08, 2010 7:46 PM
To: [email-masked]
Subject: Re: [v6ops] ULA & Basic Requirements for IPv6 Customer Edge
Routers

Yours,

Ran

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

---

From: james woodyatt <[email-masked]>
Date: Wed, 08 Dec 2010 19:13:21 -0800

On Dec 8, 2010, at 17:28, Hemant Singh (shemant) wrote:
> 
> A very fundamental nature of IPv6 is to support multiple IPv6 addresses on a network interface.  Since the ULA has global scope, the ULA is just like any other IPv6 global address provisioned on a network interface. Thus we cannot back off from the ULA as James is asking of.  Any network interface for IPv6 of an IPv6 node has got to implement the RFC 4193 ULA prefix generation algorithm.  If the ULA prefix generation be turned off for default is desired, I suppose we could discuss the default behavior. That is the only issue at hand to resolve.

So it is your position, and the position of at least one of the chairs apparently, that the coexistence problem I describe in <http://www.ietf.org/mail-archive/web/v6ops/current/msg06363.html> does not fall within the charter of V6OPS to consider.  Good to know.

I wonder if all the authors of I-D.ietf-v6ops-ipv6-cpe-router agree with that position.  If so, then I suppose I'll take my case elsewhere.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Fred Baker <[email-masked]>
Date: Wed, 8 Dec 2010 19:19:16 -0800

Being the chair in question, let me answer for myself. In context, speaking as a random engineer, not a chair, in case there is any doubt.

I think the coexistence problem, and solutions for it, are real. I don't think making a long-term ruling that makes it difficult for a CPE router to support a routed network within the home in order to work around a relatively short term problem is the wrong trade-off, and contradicts the advice the IETF has been giving the RIRs regarding prefix lengths to edge networks.

---

From: Erik Kline <[email-masked]>
Date: Wed, 8 Dec 2010 21:25:04 -0800

If a CPE ships that both serves a ULA and advertises itself as a
default router w/o also advertising a global prefix it's going to be a
problem.

And before you jump up and say "yes, but that's obviously a bug" let
me remind you of recently rumoured CPEs that advertise 2001:db8:: into
the home!  *That's* going to sink the ship if they become popular.

In fact, 2001:db8:: needs to be added to the document as something to
be treated similarly to ULA space (or simply forbidden).  I don't see
any reference to RFC 5156, but perhaps someone could sweep through and
make sure that even the pathological cases are addressed (pardon the
pun).

[2001:db8:: should probably be classified with ULA in 3484bis as well.
 Maybe it is, but I haven't checked.]

Let me also say that I'm a fan of stable addressing in a routed home
without NAT66.  [In /my/ routed home...which I agree to fix and
generally know how to maintain.]  I still believe we can get there.

But it definitely looks like we'll be keeping the AAAA whitelisting
program until the UNION of [v6-capable-cpe, happy-eyeballs,
multihome-sans-nat, ...] is rolled out.  Because the mix of bugs that
are currently in the wild, and the bugs that are soon to arrive, seem
to need almost all these fixes.

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 08 Dec 2010 23:45:11 -0800

On 12/8/10 7:19 PM, Fred Baker wrote:
> Being the chair in question, let me answer for myself. In context,
> speaking as a random engineer, not a chair, in case there is any
> doubt.
> 
> I think the coexistence problem, and solutions for it, are real.

The previous 106 messages in the thread seem to imply it's real as well.

> I
> don't think making a long-term ruling that makes it difficult for a
> CPE router to support a routed network within the home in order to
> work around a relatively short term problem is the wrong trade-off,

I had trouble with the succession of negatives.

> and contradicts the advice the IETF has been giving the RIRs
> regarding prefix lengths to edge networks.

but I agree with this as well.

>>> A very fundamental nature of IPv6 is to support multiple IPv6
>>> addresses on a network interface.  Since the ULA has global
>>> scope, the ULA is just like any other IPv6 global address
>>> provisioned on a network interface. Thus we cannot back off from
>>> the ULA as James is asking of.  Any network interface for IPv6 of
>>> an IPv6 node has got to implement the RFC 4193 ULA prefix
>>> generation algorithm.  If the ULA prefix generation be turned off
>>> for default is desired, I suppose we could discuss the default
>>> behavior. That is the only issue at hand to resolve.
>> 
>> So it is your position, and the position of at least one of the
>> chairs apparently, that the coexistence problem I describe in
>> <http://www.ietf.org/mail-archive/web/v6ops/current/msg06363.html>
>> does not fall within the charter of V6OPS to consider.  Good to
>> know.
>> 
>> I wonder if all the authors of I-D.ietf-v6ops-ipv6-cpe-router agree
>> with that position.  If so, then I suppose I'll take my case
>> elsewhere.
>> 
>> 
>> -- james woodyatt <[email-masked]> member of technical staff,
>> communications engineering
>> 
>> 
>> _______________________________________________ v6ops mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
> 
> _______________________________________________ v6ops mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 08 Dec 2010 23:48:56 -0800

> "corporate" networks that have significant internal network 

There are a lot of things including may of the proposed that are
acceptable when deliberate decisions are made by the user. the
contention on defaults is the selection of least bad options.

---

From: Mark Smith <[email-masked]>
Date: Thu, 9 Dec 2010 20:37:16 +1030

Hi,

On Wed, 8 Dec 2010 19:46:23 -0500

> list seems a bit polarised on this topic, which seems unfortunate.

I think the root of the problem is that this draft is trying to address
both general residential IPv6 (technology) end-user requirements and
global IPv6 Internet operator/customer requirements. IOW, there are two
independent requirements sets. In most cases those sets of requirements
may both exist at the same time, but they are not inter-dependent. One
set can quite validly exist in some situations without the other.

From an IPv6 end-user point of view, I don't want to be forced to have
a business relationship with an ISP just to use IPv6 technology in my
residential network, which leads to my desire to have ISP
independent address space usable across more than just a single link
(e.g. home entertainment network/vlan, sensor network/vlan, kitchen
network/vlan etc.). Even if I do have an ISP, I don't want their
service outages to impact my internal communications at all - packets
who's sources and destinations are within my residential network
shouldn't be impacted by any external events. The movie being sourced
from my NAS to my TV set shouldn't lose a single frame even if my DSL
line goes down for minutes, hours or even forever (I may have decided
to become a hi-tech hermit, and live in a cave with my trusty solar
powered generator and no Internets).

From a IPv6 Internet operator/customer point of view, I want my
customer's IPv6 Internet experience to be equivalent to and
expected to be better than IPv4 one that exists when I give
them a single IPv4 address and they NAT behind it. 

If it is impossible to successfully address both sets of requirements
with the current commonly available IPv6 technology and it's state of
deployment, which I think is the origin of the contention on the
mailing list, then I think it would be better to stop trying to address
one set of those requirements by reducing the scope of the draft. While
broadly it is a bit disappointing to suggest it, as privately addressed
IPv4 can continue to meet end-users internal home networking needs for
the time being, but publicly addressed IPv4 can't continue to provide
global Internet connectivity, I'd think it would be better to drop any
of the functions that exist in the draft to meet the residential IPv6
technology end-user requirements. So I think that the scope at the top
of the draft should be changed to reflect that it is only providing a
descriptive list of CPE features required to provide global IPv6
Internet connectivity, and that all the ULA clauses, and anything else
that doesn't exist to provide the CPE owners with successful,
plug-and-play and user friendly IPv6 Internet access should be removed.

Regards,
Mark.

---

From: Ole Troan <[email-masked]>
Date: Thu, 9 Dec 2010 11:47:16 +0100

Erik,

> default router w/o also advertising a global prefix it's going to be a

with current implementations, yes. I think we have found a solution to that with the current draft proposal (advertising ULA in RIO).

I want to emphasize again that the problem is multiprefix multihoming and not ULAs as such. removing ULAs are not going to solve the general problem of dual stack hosts == MHMP.

> Maybe it is, but I haven't checked.]

I don't think we should encode all possibly martians in this document or 3484.
that there is a CPE implementation (blush) that advertises the documentation prefix is a bug. we can't be expected to change standards just because implementors get it wrong. there isn't a bug in the standards.

> generally know how to maintain.]  I still believe we can get there.

agree.

> to need almost all these fixes.

understood. unless there is IPv6 content we will not get these problems fixed though.

cheers,
Ole

---

From: Erik Kline <[email-masked]>
Date: Thu, 9 Dec 2010 03:46:31 -0800

> I want to emphasize again that the problem is multiprefix multihoming and not ULAs as such. removing ULAs are not going to solve the general problem of dual stack hosts == MHMP.

If that's truly the case then how about we defer ULA recommendations
for a later document?

> that there is a CPE implementation (blush) that advertises the documentation prefix is a bug. we can't be expected to change standards just because implementors get it wrong. there isn't a bug in t…

Hold on to your hat there, your Norwegianness.  I would certainly
consider the lack of a normative reference to the contemporaneous
canonical martians RFC to be at least an OVERSIGHT.

Seriously, consider:  all non-routeable global unicast martians are
fundamentally indistinguishable from ULAs.  Now, near as I can tell
that's just the doc prefix and ORCHID right now.

Some text to that effect should appear, i.e. you may not need to call
each prefix out by name but you can group them all together by
describing the common properties that make them problematic.
Otherwise, somebody's gonna advertise 2001:10::/28, you know this.
;-)

> understood. unless there is IPv6 content we will not get these problems fixed though.

Understood.  I look forward to AAAAs on cisco.com for Cisco customers.  ;-)

---

From: Ole Troan <[email-masked]>
Date: Thu, 9 Dec 2010 12:52:02 +0100

Erik,

> Otherwise, somebody's gonna advertise 2001:10::/28, you know this.

indeed. I haven't seen scientific studies on this, but I'm quite convinced that the people who do this, don't read RFCs either.

in _any_ case a host will have multiple addresses that will have different reachability. be it RFC1918 space, global IPv4 addresses, addresses that are blocked by some random firewall upstream, global IPv6 addresses used for walled garden (see NTT)...
there is nothing we can do in RFCs or this draft to change that. apart from putting happy eyeballs on standards track.

> Understood.  I look forward to AAAAs on cisco.com for Cisco customers.  ;-)

+1.

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Fri, 10 Dec 2010 10:18:32 +0100

Le 9 déc. 2010 à 04:13, james woodyatt a écrit :

> I wonder if all the authors of I-D.ietf-v6ops-ipv6-cpe-router agree with that position.

>  If so, then I suppose I'll take my case elsewhere.

The fact that mandatory support of ULAs in unmanaged CPEs would be unnecessary complexity imposed on ordinary customers is a subject that, in my understanding, does belong to v6ops.
(Otherwise I wonder what operational considerations mean).

Please don't give up here.

RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 10 Dec 2010 10:23:24 +0100

> I think the coexistence problem, and solutions for it, are real. I don't think making a long-term ruling that makes it difficult for a CPE router to support a routed network within the home in orde…

That's where my proposal of a reserved local prefix fc00::/16 (mail to Ole, and mail to Brian) comes as a solution:
It supports routed networks
It doesn't impose ULA support for CPEs that target unmanaged networks.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 10 Dec 2010 15:57:43 +0100

Le 9 déc. 2010 à 11:07, Mark Smith a écrit :

>> other folks apparently wanting to prohibit ULA support.

Rather than for prohibiting ULAs, the demand I have seen is for making them optional.
The valuable reason for this demand is that supporting ULAs in CPEs is more complexity than needed in unmanaged CPEs.

> ...
> network/vlan etc.).

For this, having in IPv6 a reserved prefix can be sufficient (in addition to ULAs, which remain possible).
Wherever an IPv6 private prefix is needed, the same flexibility is thus available in IPv6 as that achieved in IPv4 with  RFC 1918.
 
As proposed in other mails on this list, a simple choice for this prefix would be fc00::/16:
- It conflicts neither with global unicast addresses nor with ULAs
- It consumes only 1/256 of local prefixes that aren't ULAs (i.e. starting with fc00::/7 but not fc00::/8).
This seems to me a simple solution to a problem that this discussion presents so far as difficult.

> ...
> one set of those requirements by reducing the scope of the draft.

It shouldn't be difficult to say that ULAs are optional for unmanaged CPEs, independently of their status for managed CPEs.

For managed CPEs, my personal preference would be to keep ULAs optional, leaving it to vendors to decide what they find appropriate, but this is IMHO much less important than the previous point.
 
Regards,
RD

---

From: Thomas Herbst <[email-masked]>
Date: Fri, 10 Dec 2010 08:58:16 -0800

Making ULA's optional is the same as doing nothing.  It does not fix any real or perceived issues with ULA's and hosts, it does not enable connectivity for those networks requiring zero configuration routed topologies without the assurance of stable global addressing from an ISP.  

Actually, it is slightly worse than doing nothing because there is an implicit claim that some problem was solved by doing the CPE document.

tom

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rémi Després
Sent: Friday, December 10, 2010 6:58 AM
To: Mark Smith
Cc: [email-masked]; RJ Atkinson
Subject: Re: [v6ops] ULA & Basic Requirements for IPv6 Customer Edge Routers

 

 
Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 10 Dec 2010 18:48:17 +0100

Le 10 déc. 2010 à 17:58, Thomas Herbst a écrit :

> Making ULA's optional is the same as doing nothing.  It does not fix any real or perceived issues with ULA's and hosts,

> it does not enable connectivity for those networks requiring zero configuration routed topologies without the assurance of stable global addressing from an ISP.

Did you note that I proposed, together with making ULAs optional, that a well known prefix could be used in place of ULAs.
It can be used, with zero configuration, where global addressing from an ISP isn't used (whatever the reason).

IMHO, most of those who have maintained a network would prefer, for their private addressing, a stable fc00::/16 prefix to a ULA, i.e. to a randomly constructed /48 that may change in case of factory reset of their CE.

By the way,  the ULA-3 rule says that "the value of the ULA prefix SHOULD be user configurable".
This defeats the insurance that ULAs of two independent sites have a negligible probability to be equal, although it is a key property of ULAs.

> Actually, it is slightly worse than doing nothing because there is an implicit claim that some problem was solved by doing the CPE document.

The remainder of the document is IMHO sufficient to justify its existence.
It's just a pity what James Woodyatt says about it be flatly ignored, while he is in charge of one of the actually deployed CEs.

Regards,
RD

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 10 Dec 2010 10:57:25 -0800

On 12/10/10 9:48 AM, Rémi Després wrote:

> By the way,  the ULA-3 rule says that "the value of the ULA prefix
> SHOULD be user configurable". This defeats the insurance that ULAs of
> two independent sites have a negligible probability to be equal,
> although it is a key property of ULAs.

The necessity of being able to support user configurable addressing when
required should not be lost on anyone...

We should be extremely careful about being proscriptive about what you
cannot do.

---

From: Fred Baker <[email-masked]>
Date: Fri, 10 Dec 2010 11:20:01 -0800

> although it is a key property of ULAs.

I'm scratching my head here. Remi, are you arguing that the ability to *configure* a ULA as opposed to having the router generate it for itself means that sites are more likely to not have random prefixes?

To my way of thinking, the argument for making a ULA a /48 is to give the administration using the ULA the ability to configure 2^16 subnets within his network while having a prefix that is extremely likely to be distinct from all others. If the requirement was that every instance of a ULA in use, including within an administration's network, had to be random, ULAs would be /64's.

What is the argument for making the prefix used by a router in a network *not* be configurable?

Or, if I am misunderstanding your remark, help me out here?

---

From: "STARK, BARBARA H (ATTLABS)" <[email-masked]>
Date: Fri, 10 Dec 2010 15:12:09 -0500

> From: Rémi Després
> Did you note that I proposed, together with making ULAs optional, that
> a well known prefix could be used in place of ULAs.
> IMHO, most of those who have maintained a network would prefer, for
> their private addressing, a stable fc00::/16 prefix to a ULA, i.e. to a
> randomly constructed /48 that may change in case of factory reset of
> their CE.

One of the key reasons I see ULAs as being an important feature, is that a CE router can delegate prefixes (e.g., /56, /60, /64) from its own ULA to other routers that are downstream from it. Multiple routers are common in consumer home networks, today. Often the user wants to add their own router behind the service provider's router. And there are other reasons. Sometimes this requires minimal configuration by the user, to make it work. That's ok.

I don't understand how a stable fc00::/16 prefix would be better? Wouldn't it be likely that the downstream router thinks it owns that very same /16 and be confused if an upstream router tried to delegate a /56 from that prefix to it? Or maybe I just really don't understand. With ULA, I think it's highly likely that the 2 routers won't settle on the same Global ID, so I don't think there's a likely conflict problem. I think that was a key element to the ULA design. At least that's my reading of it. I wasn't there.

I also fail to see how management of an ULA Global ID is such an incredibly complex thing, or how it is so much more complicated than some other more static prefix. And I don't understand how this other more static prefix would have none of the potential pitfalls of an ULA. I have to admit to being very confused by this (/16 static prefix) proposal. 

I would also like to understand better if many vendors see ULA as adding considerable complexity -- I though it looked simple and elegant when I read it over. But I don't have to implement it. If it's really hard and the router implementation could easily be done wrong, then I could have my mind changed about thinking it needs to be mandatory. But if it isn't hard to do, then I think its potential long-term value to the consumer outweighs the effort of doing it.

> SHOULD be user configurable".
> This defeats the insurance that ULAs of two independent sites have a
> negligible probability to be equal, although it is a key property of
> ULAs.

This rule means to me that (1) if, for some reason, 2 routers in the same network randomly picked the same Global ID, then one of them can be changed, and (2) if the user is replacing an old router with a new one, they have the ability to enter the old ULA Global ID into the new one, and keep the same addresses. If they want. It sounds like a good idea to me.

I support saying that CE routers must be able to generate a ULA Global ID, and be able to provide a /64 from the subsequent ULA /48 for SLAAC on its interfaces. I also want the CE router to be able to automatically delegate prefixes from the ULA /48 to downstream routers, but that's a discussion for a future draft. I think that whether or not the CE router has this feature enabled must be configurable. I don't think that this configuration option needs to be up-front-and-center -- it could be hidden away on an "Advanced Configuration" screen that most users would never see, for all I care. So I don't understand suggestions that having the capability available on a CE router would confuse consumers. I also would like to see a clearly worded description of the current dangers of ULA that would lead vendors to have it off, by default, for now. I would like these words to be non-normative, so that they don't create some sort of permanent recommendation that lives on long after the reason for them is gone. 

I also think that CE router vendors are under no obligation to do things according to this draft. It's noted as an Informational draft -- not even BCP. If a vendor reads over it, and through their knowledge of their business strategy, customer base, etc. chooses not to abide by one or more of the recommendations, then so be it. I doubt that consumers will know enough to ask "is this router compliant to the IETF CE router RFC?" They'll look at the vendor name on the box, the price, look for a few key words (e.g., Ethernet, Wi-Fi, maybe even IPv6), and make a purchasing decision.

---

From: Erik Kline <[email-masked]>
Date: Fri, 10 Dec 2010 14:26:46 -0800

> IMHO, most of those who have maintained a network would prefer, for their private addressing, a stable fc00::/16 prefix to a ULA, i.e. to a randomly constructed /48 that may change in case of facto…

This seems to me to be indistinguishable from rfc1918 and I see a
clear (and short) path from this to everyone wanting (nee "needing")
NAT66.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Dec 2010 11:37:13 +1300

> clear (and short) path from this to everyone wanting (nee "needing")

Exactly; that's really why we scrapped site-local in the first place.

ULAs have global scope for a reason.

   Brian

---

From: james woodyatt <[email-masked]>
Date: Fri, 10 Dec 2010 15:06:48 -0800

On Dec 10, 2010, at 14:37, Brian E Carpenter wrote:
> 
> Exactly; that's really why we scrapped site-local in the first place.  ULAs have global scope for a reason.

It has occurred to me that the combination of NAT64+DNS64 and <http://tools.ietf.org/html/draft-mrw-nat66> in the IPv6 CE router would be the obvious way "forward" after the inevitable failure of dual-stack hosts to be upgraded to fix the coexistence problem with ULA-only prefixes in a timely manner.

Scare quotes, because I'm sure not everyone agrees that this would be progress.  Though I suppose I could be surprised... I've been surprised before at the consensus that emerges in IETF.

---

From: Mark Smith <[email-masked]>
Date: Sat, 11 Dec 2010 10:35:52 +1030

Hi Remi,

On Fri, 10 Dec 2010 15:57:43 +0100

> Wherever an IPv6 private prefix is needed, the same flexibility is thus available in IPv6 as that achieved in IPv4 with  RFC 1918.

a.k.a. site-locals. We've been there, done that, don't want to go
there again. You might want to review the site locals deprecation RFC
for discussion of the issues that usually occur when unicast addressing
is duplicated. Don't think RFC1918 is that good, most, if not all of the
problems in that RFC also apply to them. (Personally, I was "burned"
for two months by the RFC1918 VPN issues when working on the
development an IPsec VPN service.)

(The drawback I mentioned about applications having to track
interfaces when using link locals falls into that catagory. That
problem isn't much different to the site-local/site-id issue, just on a
smaller scale.)

> For managed CPEs, my personal preference would be to keep ULAs optional, leaving it to vendors to decide what they find appropriate, but this is IMHO much less important than the previous point.

While I like the idea of ULAs, and as I've said would prefer to to keep
them in a "simple CPE baseline feature set", I think the draft should be
kept as simple as possible, to help vendors deliver basic and simple
CPE as soon as possible, and limiting itself to providing the
necessary functions for global IPv6 Internet connectivity.

My experience with a few CPE vendors who're working on IPv6 support is
that their understanding of IPv6 and it's functional goals and
differences from IPv4 is that they're very limited at the
moment. Keeping to the required function set minimal, and keeping them
to a implement *and* enable requirement would be very beneficial.

Regards,
Mark.

(some examples of what I've seen:

- CPE ignoring the M bit being set to zero on the RAs it receives on
  the WAN interface, and attempting to perform stateful DHCP rather
  than SLAAC.

- CPE not having a stateless DHCPv6 implementation available at all on
  the LAN interface for service parameter distribution to end-nodes.

- CPE failing to perform DHCPv6-PD successfully because the
  BRAS/LNS supplies other options such as SIP and SNTP server in the
  DHCPv6-PD transaction. (I do this on the BRAS/LNS so that these SIP,
  SNTP etc. parameters can be propagated to the LAN interface(s), so
  that e.g. the hardest thing involved in getting a dial tone on a VoIP
  handset to work is to plug it in to an ethernet socket.)

- CPE announcing a hop count of 255 in RAs on the LAN interface.

- CPE that "supports" ULAs setting the random ID component to all zeros.

- CPE announcing an 1460 MTU option in RAs on the LAN interface,
  despite the MTU of the PPP WAN interface being 1492. Whether the MTU
  option on LAN interface should be used at all, and setting it to the
  MTU of the PPP WAN session, is another question I'm not completely
  sure of the answer to).

- CPE firewalls only permitting TCP or UDP through to the end-nodes,
  despite IPv6 restoring the ability to have end-to-end reachability
  for other beneficial transport layer protocols such as DCCP and SCTP.
  The firewall in question doesn't even allow things like IPsec
  inbound either. Even then I still haven't managed to get inbound TCP
  through it for some throughput testing.

So in summary, my opinion is that for the most part, CPE vendors are
currently treating IPv6 as no more than IPv4 with bigger addresses,
rather than understanding the multiple issues with IPv4 and IPv4 NAT
that IPv6 is designed to overcome.)

---

From: Rémi Després <[email-masked]>
Date: Sat, 11 Dec 2010 07:21:49 +0100

> clear (and short) path from this to everyone wanting (nee "needing")

I miss the point:
- making ULAs a MAY rather than a MUST (what I propose) REDUCES the incentive to use NAT66
- the rfc1918-like IPv6 prefix should also be a MAY, as a simplified alternative to ULAs, applicable only where private addressing is chosen to apply, whatever the reason.

RD

---

From: Rémi Després <[email-masked]>
Date: Sat, 11 Dec 2010 11:11:25 +0100

Hello, Barbara,

Thank you for the detailed reaction.
More comments below.

> One of the key reasons I see ULAs as being an important feature, is that a CE router can delegate prefixes (e.g., /56, /60, /64) from its own ULA to other routers that are downstream from it.

What can be done on this point with a randomly chosen /48 can also be done with a fixed /16.

> Multiple routers are common in consumer home networks, today. Often the user wants to add their own router behind the service provider's router. And there are other reasons. Sometimes this requires minimal configuration by the user, to make it work. That's ok.

Same comment.

> I don't understand how a stable fc00::/16 prefix would be better? Wouldn't it be likely that the downstream router thinks it owns that very same /16 and be confused if an upstream router tried to delegate a /56 from that prefix to it? Or maybe I just really don't understand.

Same comment.

> With ULA, I think it's highly likely that the 2 routers won't settle on the same Global ID, so I don't think there's a likely conflict problem. I think that was a key element to the ULA design. At least that's my reading of it. I wasn't there.

I wasn't either, but random generation of /48 prefixes, with conservation in non-volatile memory and *some* reset mechanism, is a complexity that shouldn't be imposed to *all* CEs:
- It is unnecessary complexity for typical residential sites
- If a mobile phone acts as a router (as some already do in IPv4), should it create ULA prefixes?  If yes when?    

> I also fail to see how management of an ULA Global ID is such an incredibly complex thing, or how it is so much more complicated than some other more static prefix. And I don't understand how this…

It is simpler because you know beforehand what private prefix your network will have, and there is no risk that it changes after some undesirable reset. 

> I would also like to understand better if many vendors see ULA as adding considerable complexity -- I though it looked simple and elegant when I read it over.

Not "considerable" but still an unnecessary complexity. 
Some vendors should be free to avoid without conflicting with IETF "requirements". 

> But I don't have to implement it. If it's really hard and the router implementation could easily be done wrong, then I could have my mind changed about thinking it needs to be mandatory. But if it isn't hard to do, then I think its potential long-term value to the consumer outweighs the effort of doing it.

This should remain a VENDOR CHOICE, not a feature IETF says is necessary for IPv6 to be used.
I have used IPv6 in my soho network without a CPE supporting ULAs, and I am quite happy with it.  

> This rule means to me that (1) if, for some reason, 2 routers in the same network randomly picked the same Global ID, then one of them can be changed, and (2) if the user is replacing an old router…

ULAs can be fine for what they do, but, again, shouldn't be made mandatory.
Do you believe that CEs supporting ULA without some form of NAT66 is a useful combination?
*Is IETF stealthily making some form of NAT66 mandatory in all CEs?*
Is this reasonable?

> I support saying that CE routers must be able to generate a ULA Global ID, and be able to provide a /64 from the subsequent ULA /48 for SLAAC on its interfaces. I also want the CE router to be able to automatically delegate prefixes from the ULA /48 to downstream routers, but that's a discussion for a future draft.

Then, why not keeping ULAs optional, at least in this current draft.
If too many find a MAY too permissive for ULAs, *could a SHOULD be a reasonable compromise?*.

> I think that whether or not the CE router has this feature enabled must be configurable. I don't think that this configuration option needs to be up-front-and-center -- it could be hidden away on an "Advanced Configuration" screen that most users would never see, for all I care.

Agreed. 
Where ULAs are supported, this should be the right way. 

> So I don't understand suggestions that having the capability available on a CE router would confuse consumers.

A vendor of residential CEs that includes ULAs, be it with a NAT66 or without, is likely to have more maintenance calls than one that doesn't.
Operational costs for customers and vendors would then be higher.
 
> I also would like to see a clearly worded description of the current dangers of ULA that would lead vendors to have it off, by default, for now. I would like these words to be non-normative, so that they don't create some sort of permanent recommendation that lives on long after the reason for them is gone. 

The point is that in a residential network, working with the ISP provided prefix is perfectly fine.
Everything else can be felt as a nuisance. 
That is what I have been using extensively since 2008 with no desire to get anything different.

> I also think that CE router vendors are under no obligation to do things according to this draft. It's noted as an Informational draft -- not even BCP. If a vendor reads over it, and through their…

Well, the draft says "This document specifies requirements for an IPv6 Customer Edge (CE) router."
If endorsed by IETF, any feature with a MUST means that, to conform to IETF requirements, it has to be supported.
The point is that ULA support shouldn't be *on a lower footing* than other features that have a MUST.  

Regards,
RD

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 12 Dec 2010 08:40:29 +1300

> - making ULAs a MAY rather than a MUST (what I propose) REDUCES the incentive to use NAT66

I disagree. ULAs are how you can give your printers a fixed address even if your
PA prefix changes every time you reboot the CPE. It's PI that provides the
incentive to use some form of NAT.

> - the rfc1918-like IPv6 prefix should also be a MAY, as a simplified alternative to ULAs, applicable only where private addressing is chosen to apply, whatever the reason.

RFC 3879!

   Brian

---

From: Ole Troan <[email-masked]>
Date: Sat, 11 Dec 2010 20:45:44 +0100

Remi,

> - If a mobile phone acts as a router (as some already do in IPv4), should it create ULA prefixes?  If yes when?  

what is the complexity? having a random number generator?
a CE could very well just generate a ULA prefix based on its MAC address. no persistent storage required.

cheers,
Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 11 Dec 2010 21:57:54 +0100 (CET)

On Fri, 10 Dec 2010, james woodyatt wrote:

> It has occurred to me that the combination of NAT64+DNS64 and 
> <http://tools.ietf.org/html/draft-mrw-nat66> in the IPv6 CE router would 
> be the obvious way "forward" after the inevitable failure of dual-stack 
> hosts to be upgraded to fix the coexistence problem with ULA-only 
> prefixes in a timely manner.

In my brief experience with DNS64+NAT64 I'd say it's a very limited way 
forward generally, due to a lot of applications/os not being IPv6 enabled 
"enough".

I like the NAT64 functionality (well, "like"), but DNS64 requires a lot of 
things to work. I'd like to run DNS64 plus also have the ability to have 
the IP stack in the computer do "IPv4 NAT" by means of having it take all 
IPv4 reachability requests and do the same thing the DNS64 resolver is 
doing (ie map v4 space into some v6 prefix handled by the NAT64 gateway).

The NAT64 prefix needs to be handed out by some dynamic mean or even hand 
configured into the device. I think I saw an RFC just published that had 
this functionality if I'm not mistaken. This would also mean an Windows XP 
machine with added such client would be able to run in a NAT64 environment 
(since DNS64 doesn't work for XP).

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: james woodyatt <[email-masked]>
Date: Sat, 11 Dec 2010 17:04:59 -0800

> a CE could very well just generate a ULA prefix based on its MAC address. no persistent storage required.

Or we could eat fd00::/16, reserving the leftmost 24 bits of the 40-bit global ID for IEEE OUI space, then allowing the vendor that owns each OUI to eat the rest of the Global ID and the Subnet ID however it sees fit.  One perfectly reasonable approach would be to push the rest of a 48-bit MAC address there, leaving 8 bits for Subnet ID, and the last 64 bits, of course, for Interface ID.

---

From: james woodyatt <[email-masked]>
Date: Sat, 11 Dec 2010 17:09:15 -0800

> Or we could eat fd00::/16, reserving the leftmost 24 bits of the 40-bit global ID for IEEE OUI space, then allowing the vendor that owns each OUI to eat the rest of the Global ID and the Subnet ID…

Error: make that fd00::/8.  Proofread fail.

---

From: Mark Smith <[email-masked]>
Date: Sun, 12 Dec 2010 13:38:43 +1030

On Sat, 11 Dec 2010 17:09:15 -0800

> Error: make that fd00::/8.  Proofread fail.

How did the ULA problem turn into how to avoid implementing random
number generators and storing their results in CPE?

---

From: james woodyatt <[email-masked]>
Date: Sun, 12 Dec 2010 02:17:31 -0800

On Dec 11, 2010, at 19:08, Mark Smith wrote:
> 
> How did the ULA problem turn into how to avoid implementing random number generators and storing their results in CPE?

I'm not really all that supportive of the idea I just proposed, but it *does* have one trivial distinction in its favor: a 48-bit MAC address is already unmemorizable, and using it inside the ULA prefix a device generates will cut down on the number of unmemorizable bit strings associated with the device.

On the other hand, there are already a lot of good reasons to assign a persistent UUID to CPE devices and leave the MAC addresses for identifying their interfaces.  People shouldn't be asked to remember them, and the lower 40 bits of the UUID will make a fine ULA Global ID field.

---

From: Rémi Després <[email-masked]>
Date: Mon, 13 Dec 2010 11:06:58 +0100

Le 11 déc. 2010 à 20:40, Brian E Carpenter a écrit :

> PA prefix changes every time you reboot the CPE.

No sure we really disagree here:
- A Well known Private Prefix  is ALSO a mean to give your printers a fixed address every time an ISP changes the PA prefix.
- This is independent from having or not having a NAT.

> It's PI that provides the

I am confused.`
(Aren't PIs the tool to use global prefixes in multihomed networks, precisely to avoid needing any NAT.)

>> - the rfc1918-like IPv6 prefix should also be a MAY, as a simplified alternative to ULAs, applicable only where private addressing is chosen to apply, whatever the reason.

The proposed Well known Private Prefix (WPP) isn't a re-precation of "site local addresses" that were deprecated by RFC 3879:
- The first of the two reasons for RFC 3879's, the "fuzzy definition of sites", was sufficient for a deprecation.
- It doesn't concern the WPP.

The second reason for RFC 3879, "ambiguity of addresses" isn't clear:
The fact that FRC 1918 addresses have leaked outside private networks doesn't imply that, with appropriate rules defined in due time, it should be reconvened in IPv6.

IMHO:
- We DO NEED ASAP a complete specification for IPv6 CPEs for networks that have internal routing based on global IPv6  prefixes.
- Everything that goes beyond should so far be optional or, better, kept for a later version (i.e. until implications on NAT66, split DNS66, referrals, and multihoming, are better understood.
- Premature MUSTs can prevent early IPv6 deployments, and deteriorate user experiences with IPv6

In particular, it should be considered that:
- There is today only one documented NAT66 proposal, the NPTv6 of draft-mrw-nat66-01.
- It has at least one serious technical problem under discussion (point 2 of a mail on the NAT66 mailing list, copy below).

Regards,
RD 

__________________________________________
De : Rémi Després <[email-masked]>
Date : 9 décembre 2010 17:15:04 HNEC
À : Fred Baker <[email-masked]>
Cc : Margaret Wasserman <[email-masked]>, NAT66 HappyFunBall <[email-masked]>
Objet : Rép : [nat66] I'd appreciate comments - an important technical problem

Le 6 déc. 2010 à 20:03, Fred Baker a écrit :
...
  ftp://ftpeng.cisco.com/fred/nat66/draft-mrw-nat66-00-01-diff.html
... I'd appreciate comments on it from this list.
...
2.
Here is, then, a further explanation on the problem I see:
- If a translation includes a last step that forces a single final result for two different intermediate results, *it cannot be reversible*.
- Sec. 8 says "If the resulting value is 0xFFFF, it is changed to 0x0000", this applying to both translation directions as confirmed in the example.
- Thus, two different original values of the 16-bit modified 16-bit word can, in the outgoing translation, give the same final value 0x0000. There is then no way in the reverse direction to determine which was the original value. 
...
_________________________________________

---

From: Rémi Després <[email-masked]>
Date: Mon, 13 Dec 2010 11:15:25 +0100

> a CE could very well just generate a ULA prefix based on its MAC address. no persistent storage required.

1. This would wot comply with RFC 4193 where ULAs are defined.

2. In any case MAC address has 6 octets where an ULA has only 5 free octets. Some hash of a Mac address might have mathematical properties that need to be checked.

3. A CPE replacement would necessitate a renumbering. (No such need with a Well known Private Prefix). 

Regards,
RD

---

From: Wes Beebee <[email-masked]>
Date: Mon, 13 Dec 2010 09:31:57 -0500

> number generators and storing their results in CPE?

What I still don't understand is what problem people have with the actual
solution which is being proposed to the problem: namely to use the RIO and
default-router announcement process to tell hosts when they have global
connectivity or not, and to allow them to use ULA's only when they have a
ULA destination to send packets to.

It seems to me that MSR and the solution that Ole proposed actually solves
the only real problem on the table, and the rest of the "discussion" can be
safely ignored.

- Wes

---

From: Rémi Després <[email-masked]>
Date: Mon, 13 Dec 2010 17:01:22 +0100

> I'm scratching my head here. Remi, are you arguing that the ability to *configure* a ULA as opposed to having the router generate it for itself means that sites are more likely to not have random p…

Yes.
If I would be forced to have ULAs, but with the freedom to configure them, I would choose fd00::/48, and suspect that many others might do the same.

With fd00::/48 I would be able to keep my local addresses stable in all circumstances (accidental factory reset, change of CPE, whatever).
Thus, I wouldn't need a post-it to remember what it is (plus, as I tend to have a poor memory, another post-it to remember where I put the first one...)

> To my way of thinking, the argument for making a ULA a /48 is to give the administration using the ULA the ability to configure 2^16 subnets within his network while having a prefix that is extremely likely to be distinct from all others.

Same understanding, and this makes sense for networks for which site mergers may be envisaged in the future.

But in my soho I don't have any such plan.
What I need is IPv6 as long as my ISP keeps it operational, and private IPv4 for dual-stack operation in all circumstances.
My current CPE does this, and shouldn't be *required* by IETF to also support ULAs.

> If the requirement was that every instance of a ULA in use, including within an administration's network, had to be random, ULAs would be /64's.
> 

The Point is only that ULAs shouldn't be configured by hand to keep their property of being statistically unique.
(My understanding of RFC 4193 is that a CPE that supports ULAs should support the "Pseudo-Random Global ID Algorithm" of section 3.2.2, copied below, and should not replace it by a human produced value.)

Note that I wouldn't have any problem with a configured local prefix provided it isn't a ULA (i.e. a /48 starting with fd00::/8, and generated according to RFC 4193).
As a matter of fact I proposed that fc00::/16 would be a well known private prefix (like the 10/8 of IPv4), to be recommended where ULAs aren't needed but where a permanent IPv6 prefix is needed. 

Note also that my main point in this discussion is that ULA support should be optional, at least in residential CPEs, and at least until implications on NAT66, split DNS66, referrals, and multihoming, are better understood and documented.

Regards,
RD

APPENDIX (from RFC 4193 on ULAs): 
3.2.2.  Sample Code for Pseudo-Random Global ID Algorithm 

   The algorithm described below is intended to be used for locally
   assigned Global IDs.  In each case the resulting global ID will be
   used in the appropriate prefix as defined in Section 3.2.

     1) Obtain the current time of day in 64-bit NTP format [NTP].

     2) Obtain an EUI-64 identifier from the system running this
        algorithm.  If an EUI-64 does not exist, one can be created from
        a 48-bit MAC address as specified in [ADDARCH].  If an EUI-64
        cannot be obtained or created, a suitably unique identifier,
        local to the node, should be used (e.g., system serial number).

     3) Concatenate the time of day with the system-specific identifier
        in order to create a key.

     4) Compute an SHA-1 digest on the key as specified in [FIPS, SHA1];
        the resulting value is 160 bits.

     5) Use the least significant 40 bits as the Global ID.

     6) Concatenate FC00::/7, the L bit set to 1, and the 40-bit Global
        ID to create a Local IPv6 address prefix.

   This algorithm will result in a Global ID that is reasonably unique
   and can be used to create a locally assigned Local IPv6 address
   prefix.

---

From: james woodyatt <[email-masked]>
Date: Mon, 13 Dec 2010 09:26:00 -0800

On Dec 13, 2010, at 06:31, Wes Beebee wrote:
> 
> What I still don't understand is what problem people have with the actual solution which is being proposed to the problem

It doesn't solve the coexistence problem associated with advertising ULA prefixes in PIO options without also advertising routable prefixes at the same time.  What I don't understand is why the coexistence problem doesn't seem to matter to anyone.

p.s. The draft should be withdrawn and brought back into the working group to fix the coexistence problem.

---

From: Fred Baker <[email-masked]>
Date: Mon, 13 Dec 2010 09:34:49 -0800

At this point, unless someone corrects me, it looks to me like you're the only person calling for that. Hence, we indeed would appear to have rough consensus. If you want to change with the draft says in a material way, I would suggest putting whatever updates you want into cpe-router-bis.

---

From: Ole Troan <[email-masked]>
Date: Mon, 13 Dec 2010 19:23:09 +0100

James,

> It doesn't solve the coexistence problem associated with advertising ULA prefixes in PIO options without also advertising routable prefixes at the same time.  What I don't understand is why the coe…

please don't put words in our collective mouths... the coexistence problem was the reason
why this was brought back up in the first place.

with the proposal in the draft, a host without global IPv6 connectivity with ULA
will have:

- a private (typically) IPv4 address
- a 0/0 route to the IPv4 router
- a ULA IPv6 address
- a route for the ULA prefix to the IPv6 router

note the absence of a default route.
the lack of a default route should make the host stack give up on IPv6 immediately.
I believe Tore has tested this in a few implementations where it worked as expected (while he found a bug in another one).

[...]

cheers,
Ole

---

From: james woodyatt <[email-masked]>
Date: Mon, 13 Dec 2010 10:37:47 -0800

On Dec 13, 2010, at 09:34, Fred Baker wrote:
> 
> If you want to change with the draft says in a material way, I would suggest putting whatever updates you want into cpe-router-bis.

Unless I completely fail to understand the state of play here, the need for rough consensus passed a long time ago, when I wasn't paying particularly close attention to the progress of this draft.  I am quite surprised that nobody else noticed the coexistence problem until the draft proceeded to the RFC Editor and implementations started showing up in the real world.  The only way now to prevent the coexistence problem that concerns me is for the authors of the draft to withdraw it back into the working group.  That's what I'm making a public plea for them to do.

If the authors won't withdraw the draft, then I'm sure the coexistence problem will be addressed some other way, most likely by major content providers pushing back their IPv6 production schedules until enough hosts have been upgraded or retired that the damage to their IPv4 service at broken hosts will be acceptable to them.  Which they already seem to be doing, anyway, so maybe it doesn't matter.

---

From: james woodyatt <[email-masked]>
Date: Mon, 13 Dec 2010 10:40:52 -0800

> note the absence of a default route.

The language you proposed does not actually require the lack of a default route in this scenario.  I proposed this:

  L-x:   An IPv6 CE router MUST NOT advertise as a default router with
         Router Lifetime greater than zero whenever all of its
         configured and delegated prefixes are ULA prefixes.

The authors rejected that.

---

From: Wes Beebee <[email-masked]>
Date: Mon, 13 Dec 2010 14:00:25 -0500

> The authors rejected that.

Note that the language that Ole supported subsumed this requirement.
Namely, if the CPE router has no default router, it will have no global
prefixes - only the ULA's, and it MUST NOT advertise as a default router to
the hosts downstream from it.  We are in violent agreement.  Problem solved.

- Wes

---

From: Ole Troan <[email-masked]>
Date: Mon, 13 Dec 2010 19:57:03 +0100

James,

>         configured and delegated prefixes are ULA prefixes.

agree. the corner case where you have a default route but you have no global prefixes are not covered. we should add that.

if we got that in, would you be happy with that set of changes to cover the coexistence problem with ULAs?

cheers,
Ole

---

From: james woodyatt <[email-masked]>
Date: Mon, 13 Dec 2010 11:19:14 -0800

On Dec 13, 2010, at 11:00, Wes Beebee wrote:
> 
> Note that the language that Ole supported subsumed this requirement. Namely, if the CPE router has no default router, it will have no global prefixes - only the ULA's, and it MUST NOT advertise as a default router to the hosts downstream from it.

Ole Troan says he believes that's covered by language he has already proposed, but I don't see it in the draft that is in the RFC Editor queue.  Maybe I'm not searching for the right text in my copy of the email archive.  The nearest thing I see is in the message he sent December 6 that included this proposed text:

  G-4:  By default an IPv6 CE router that has no default router on its
        WAN interface MUST NOT advertise itself as an IPv6 default
        router on its LAN interfaces.  That is, the "Router Lifetime"
        field is set to zero in all Router Advertisement messages it
        originates [RFC4861].

  G-5:  By default if the IPv6 CE router is an advertising router and
        loses its IPv6 default router on the WAN interface, it MUST
        explicitly invalidate itself as an IPv6 default router on each
        of its advertising interfaces by immediately transmitting one
        or more Router Advertisement messages with the "Router
        Lifetime" field set to zero [RFC4861].

This is not in the current draft, and anyway, it does not solve the problem, because an IPv6 CE router may have a default router on its WAN interface without having any globally routable prefix configured or delegated, in which case it will not be prevented from causing the coexistence problem that concerns me.

My proposed text explicitly disallows IPv6 CE routers from failing coexistence with IPv4 in the face of current host implementations.  Ole's text does not.

> Problem solved.

Problem cannot be solved in AUTH48.  According to IETF procedure, as I understand it, the draft must be withdrawn and restarted in the working group to address the problem satisfactorily.

---

From: Fred Baker <[email-masked]>
Date: Mon, 13 Dec 2010 11:24:44 -0800

On Dec 13, 2010, at 11:19 AM, james woodyatt wrote:

> Ole Troan says he believes that's covered by language he has already proposed, but I don't see it in the draft that is in the RFC Editor queue. 

That's because every time he points it out you go through the roof. Would you find his proposed text suitable? If so, he can post it.

---

From: Wes Beebee <[email-masked]>
Date: Mon, 13 Dec 2010 14:30:55 -0500

I see now that the two existing requirements do not exactly subsume the
following requirement (there's a corner case missing):
 
> agree. the corner case where you have a default route but you have no global
> prefixes are not covered. we should add that.
> 

I'm OK with adding the above suggested text, if James is OK with it.

- Wes

---

From: james woodyatt <[email-masked]>
Date: Mon, 13 Dec 2010 11:55:46 -0800

On Dec 13, 2010, at 10:57, Ole Troan wrote:
> On Dec 13, 2010, at 10:40, james woodyatt wrote:
>> 

It would help greatly, but I remain concerned that advertising ULA prefixes in PIO options, even with Router Lifetime = 0, or making ULA addresses available in IA options with DHCPv6, will allow a host that is fully compliant with RFC 4861 (and RFC 3315) but not with either I-D.wing-v6ops-happy-eyeballs-ipv6 or I-D.fujisaki-dhc-addr-select-opt, to fail IPv4 coexistence in the presence of another default router on the LAN with Router Lifetime > 0.

Admittedly, that's a much less pressing concern, but we're trying to be future-proof here, right?  If the ULA section were edited to provide an explicit warning about of this minor aspect of the IPv4 coexistence problem, then I suppose I could be persuaded not to object strenuously.

The procedural problem remains open.

---

From: Fred Baker <[email-masked]>
Date: Mon, 13 Dec 2010 11:55:50 -0800

Chair hat most definitely off.

> My current CPE does this, and shouldn't be *required* by IETF to also support ULAs.

So your solution to configuration of the router and local access in general is not IPv6, but IPv4. I'm listening for Randy's comment about IPv6 networks...

> (My understanding of RFC 4193 is that a CPE that supports ULAs should support the "Pseudo-Random Global ID Algorithm" of section 3.2.2, copied below, and should not replace it by a human produced v…

If that is true, then there is no way to introduce subnets in a network using a ULA, unless somehow you have a site-wide (hmmm... definition of a "site" that doesn't require manual configuration...) way to distribute the /48 and on the interfaces in question only configure the subnet number. Since RFC 4193 makes a point of talking about subnets and there is no standardized mechanism for what I described, I'm pretty certain that what you are suggesting is not the intent of RFC 4193. RFC 4193 is a way to get a prefix to use in your site, not a way that every router on every interface is expected to create prefixes without configuration.

> Note also that my main point in this discussion is that ULA support should be optional, at least in residential CPEs, and at least until implications on NAT66, split DNS66, referrals, and multihomi…

If your main point is that ULAs should not be required-to-be-configured, whether that configuration is manual or automatic, I think there is general consensus on that point. The question being debated is whether it is appropriate to require a CPE Router to be able to generate a ULA on command, as opposed to *only* being manually configurable with one.

Thinking out loud here... There are two lines of reasoning regarding the velocity of the transition. 

One line of reasoning says that IPv4 will continue for the indefinite future; there is no argument for pulling it out of Windows/Linux/etc, and interoperation with deployed equipment like printers and older PCs will force it. 

The other line of reasoning would suggest that networks will tend to prefer to configure-and-operate one technology or the other but not both, and will therefore in time squeeze the *use* of IPv4 out of their networks in the same way and for the same reason that they have delayed configuration of IPv6. Adding IPv6 support to an existing printer-or-whatever is a matter of a software update, or (if my experience with printers is anything to point to) to watch them die their usual untimely death and replace them with equipment that supports IPv6 (which is why my printer supports IPv6). That second line of reasoning would actually suggest that once we reach the tipping point - once traffic is O(50%) IPv6, half-or-more of deployed equipment is IPv6-capable, and content is generally available on IPv6, gravity will pull in the direction of IPv6, and will have as strong an attraction as IPv4 had a year ago - and growing. One could easily imagine as early as 2013 or 2014 people asking a very serious question as to whether it is yet time to shut down IPv4.

As a vendor, I can tell you that access ISPs as a class are having "interesting times". The Cable Modem networks are moving in the direction of DOCSIS 3.0 and IPv6 deployment, as Comcast has made very public. Some are using 6rd in the near term to work around existing DOCSIS 2.0 deployment; every one I have spoken with expects to have dual stack deployment in the not-to-distant future, and expects IPv6-only at some point in the future. The DSL networks I am speaking with have a problem in their access path; some of the equipment is difficult to upgrade and is IPv4-only. Many are talking about a dual stack core with a 6rd path over the troublesome access equipment; at least two are talking about literally replacing the IPv4 networks with IPv6 and running IPv4 as an overlay - ds-lite. For them, there is also a technology question: would it make more sense to stay with DSL technology with its speed and distance limitations, or while changing out the access path change out the last mile to fiber-to-the-<something>? Before you say "no brainer", follow the money. I'm not hearing consensus, but I am hearing the question.

In writing a specification like this, I think we have to make educated guesses about the future, and make statements that we can support now and expect to be able to continue to support several years hence. Usually, when we have written such (RFCs 1122/1123, 1812, 4294), we have been able to assume that present status/practice was a good indicator of future status/practice; in this case, both lines of reasoning say that present practice (IPv4-only networking for the most part) is absolutely *not* a prediction of the future, and the question is whether the medium term will be more predominantly IPv4+IPv6 or IPv6-only. We have to believe that in the long term (a decade out), IPv6-only networks will be increasingly prevalent, especially given that we have some now.

Game theory tells me to choose strategies that give me lots of options, so that I can adapt to circumstances that change in the course of play. In chess, one would talk about controlling the center of the board. Choosing a course of action that optimizes for one possibility but not another works against me if the other becomes reality. If in the long term IPv4 is going to be a headache and the issues are more readily solved using a ULA, then in the long term I want the option of turning off IPv4 and using a ULA. If in the medium term I might be able to use existing IPv4 configurations or the situation might be as in the long term, then providing the ability to use IPv4 *or* a ULA makes sense. Requiring me to use IPv4 for those circumstances primarily guarantees that the specification will be obsolete in the long term, and runs the risk of it being obsolete in the medium term.

Given that context, I don't see why we would not RECOMMEND (in cpe-router-bis) that CPE routers have the *capability* of doing the math to generate a ULA, for the purposes of configuring an interface with it, and that routers in general be configurable with a ULA-derived subnet, but that they not automatically do either.

---

From: james woodyatt <[email-masked]>
Date: Mon, 13 Dec 2010 12:07:10 -0800

> Admittedly, that's a much less pressing concern, but we're trying to be future-proof here, right?  If the ULA section were edited to provide an explicit warning about of this minor aspect of the IP…

As long as the other default routers on the LAN also conform to the recommendations in [the proposed revisions to] this draft, then there shouldn't be a coexistence problem.  This is what the warning should point out.  The problem only arises when there are other routers on the LAN that advertise Router Lifetime > 0 and do not advertise any globally routable prefixes in PIO with A=1.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 13 Dec 2010 14:12:15 -0600

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of james woodyatt
Sent: Monday, December 13, 2010 3:07 PM
To: IPv6 Operations
Subject: Re: [v6ops] ULA & Basic Requirements for IPv6 Customer Edge
Routers

>As long as the other default routers on the LAN also conform to the
recommendations in [the proposed revisions to] this draft, then there
shouldn't be a coexistence problem.  This is what the warning >should
point out.  The problem only arises when there are other routers on the
LAN that advertise Router Lifetime > 0 and do not advertise any globally
routable prefixes in PIO with A=1.

This is text for the bis document because the basic IPv6 CE router
document covers the case of a single IPv6 CE router in the home with no
multi-homed WAN or LAN network segments.

Thanks much for your suggested text, though.

Hemant

---

From: Wes Beebee <[email-masked]>
Date: Mon, 13 Dec 2010 15:15:01 -0500

>> It would help greatly, but I remain concerned that advertising ULA prefixes
>> in PIO options, even with Router Lifetime = 0, or making ULA addresses
>> available in IA options with DHCPv6, will allow a host that is fully
>> compliant with RFC 4861 (and RFC 3315) but not with either
>> I-D.wing-v6ops-happy-eyeballs-ipv6 or I-D.fujisaki-dhc-addr-select-opt, to
>> fail IPv4 coexistence in the presence of another default router on the LAN
>> with Router Lifetime > 0.
>> 
>> Admittedly, that's a much less pressing concern, but we're trying to be
>> future-proof here, right?  If the ULA section were edited to provide an
>> explicit warning about of this minor aspect of the IPv4 coexistence problem,
>> then I suppose I could be persuaded not to object strenuously.
> 
> shouldn't be a coexistence problem.  This is what the warning should point
> out.  The problem only arises when there are other routers on the LAN that
> advertise Router Lifetime > 0 and do not advertise any globally routable
> prefixes in PIO with A=1.

The solution to this problem would be to go to the other router vendor and
get them to implement the recommendations in this draft.  It's hard to write
documents for vendors who don't implement them.

- Wes

---

From: james woodyatt <[email-masked]>
Date: Mon, 13 Dec 2010 12:30:30 -0800

> documents for vendors who don't implement them.

Which is why I'm suggesting informative text instead of normative.  Equipment makers that don't want to conform to these recommendations should be informed of the implications for coexistence with IPv4.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 13 Dec 2010 14:32:37 -0600

+1

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Wes Beebee (wbeebee)
Sent: Monday, December 13, 2010 2:31 PM
To: Ole Troan; james woodyatt
Cc: IPv6 Operations
Subject: Re: [v6ops] ULA & Basic Requirements for IPv6 Customer Edge
Routers

I see now that the two existing requirements do not exactly subsume the
following requirement (there's a corner case missing):
 
> if we got that in, would you be happy with that set of changes to
cover the
> coexistence problem with ULAs?

- Wes

---

From: Wes Beebee <[email-masked]>
Date: Mon, 13 Dec 2010 15:48:14 -0500

How about the following sentence?

"Failure of CE routers to comply with recommendations L-x through L-y may
result in delay or lack of connectivity in applications which only have
access to a ULA and an IPv4 address and are attempting to contact a
destination not reachable using the ULA."

- Wes

On 12/13/10 3:30 PM, "james woodyatt" <[email-masked]> wrote:

> Which is why I'm suggesting informative text instead of normative.  Equipment
> makers that don't want to conform to these recommendations should be informed
> of the implications for coexistence with IPv4.
> 
> 
> --

---

From: james woodyatt <[email-masked]>
Date: Mon, 13 Dec 2010 13:04:26 -0800

> destination not reachable using the ULA."

I don't think that adequately informs the reader about the nature of the problem to be avoided.

I propose: "An important consequence of recommendations L-x through L-y [above/below] is to assure coexistence of IPv6 route advertisements on the LAN with IPv4 service to dual-stack hosts, which may have default address selection policies that prefer IPv6 ULA addresses over IPv4 when communicating with peers available at both IPv4 and IPv6 addresses.  In the event more than one IPv6 CE router is present on the LAN, then coexistence requires all of them to conform to these recommendations.  If any single IPv6 CE router advertises itself on the LAN with Router Lifetime > 0 and no globally routable address in a PIO with A=1 or a globally routable address is configured with IA options in DHCPv6, then IPv4 coexistence cannot be assured to dual-stack hosts on the LAN."

Note well: no normative keywords.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Dec 2010 10:13:38 +1300

Rémi,

...
> (Aren't PIs the tool to use global prefixes in multihomed networks, precisely to avoid needing any NAT.)

PI provides unscalable multihoming, unless there are major changes to
the wide area routing system.

PI + NAT66 = scalable multihoming without touching the wide area routing system.

That, unfortunately, is a very strong economic incentive.

   Brian

---

From: Roger Jørgensen <[email-masked]>
Date: Mon, 13 Dec 2010 22:24:37 +0100

> Chair hat most definitely off.

lucky that only got one?:-)

<snip>

> Given that context, I don't see why we would not RECOMMEND (in cpe-router-bis) that CPE routers have the *capability* of doing the math to generate a ULA, for the purposes of configuring an interfa…

Sound to me that CPEs should have the capability to generate a ULA as
you said. However, isn't there a question of price/complexity involved
in doing that math? Probably not much but it will add something extra
to the code.

-- 

Roger Jorgensen           |
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Dec 2010 10:29:16 +1300

On 2010-12-14 03:31, Wes Beebee wrote:
...
> ULA destination to send packets to.

I'm confused. If the only IPv6 routes available are within the ULA prefix
and there's no default route, "allow" doesn't come into it. Everything else
will be instantly unreachable (like Ole said).

On 2010-12-14 07:57, Ole Troan wrote:
...
> if we got that in, would you be happy with that set of changes to cover the coexistence problem with ULAs?

In that case, I for one want to see a complete draft I can run through
rfcdiff; this is too substantive for an editorial AUTH48 fix.

On 2010-12-14 10:07, Mark Smith wrote:
...
> I think it would also think the coexistence issue, in the absence
> of ICMPv6 destination unreachables, would occur for ULA only
> devices when there are some LAN interfaces with a global + ULA prefixes
> and others that are ULA only. The current RA lifetime zero text wouldn't
> apply in that situation.

But interfaces configured with ULA only are presumably devices for
which no external access is desired by the network manager, so who cares
what happens if they try it?

    Brian

---

From: james woodyatt <[email-masked]>
Date: Mon, 13 Dec 2010 14:38:56 -0800

On Dec 13, 2010, at 13:29, Brian E Carpenter wrote:
> 
> In that case, I for one want to see a complete draft I can run through rfcdiff; this is too substantive for an editorial AUTH48 fix.

The RFC Editor has this draft in the MISSREF state, because it still needs a reference to I-D.ietf-6man-node-req-bis, which is still in active development.  There should still be plenty of time to withdraw this draft, revise it, and get it back into the queue without causing any delay in the RFC publication schedule.

---

From: Joel Jaeggli <[email-masked]>
Date: Mon, 13 Dec 2010 17:46:45 -0800

Joel's widget number 2

> in doing that math? Probably not much but it will add something extra

RFC 4193 has a really simple method if you don't have access to a high quality prng. No CPE that has enough CPU to checksum ip packets is going to have trouble generating a ULA.

---

From: Mark Smith <[email-masked]>
Date: Tue, 14 Dec 2010 19:14:15 +1030

Hi Brian,

On Tue, 14 Dec 2010 10:29:16 +1300
Brian E Carpenter <[email-masked]> wrote:

<snip>

> what happens if they try it?

My concern was the text which said that the router life time is set to
zero if only ULAs are used on the non-WAN interfaces. If a global was
assigned to just one of the LAN interfaces, then it wouldn't apply
anymore, such that RAs with non-zero lifetimes would now be sent on the
ULA only interfaces. Possibly that might be valid, because the ULA only
devices may need to communicate with the globally addressed devices on
the another other LAN interface. It would mean though that the
co-existence issue would now occur for those ULA only devices, because
they would now have a default router.

As I mentioned in my earlier reply to Hemant, the issue with have with
using RIO to overcome this when the router lifetime is zero is that it
is an optional mechanism that may not be widely implemented.

Regards,
Mark.

---

From: Tim Chown <[email-masked]>
Date: Tue, 14 Dec 2010 14:24:58 +0000

> Given that context, I don't see why we would not RECOMMEND (in cpe-router-bis) that CPE routers have the *capability* of doing the math to generate a ULA, for the purposes of configuring an interfa…

Sounds good.    The ULA requirements in draft-ietf-v6ops-ipv6-cpe-router-07 don't actually say that ULAs must be advertised; that is implied by point 1 on page 9 above the L-* requirements.    I fall into the camp of understanding 'support' to mean 'have the capability to *generate* and advertise'.   Thus in my view Point 1 could be rewritten to be more in line with the itemised requirements, which are the bits of text I read most closely when reviewing the draft previously.

I haven't yet seen a use for ULAs in my home network or my (campus) enterprise network, but then both have a single provider.

Perhaps the 'Advanced' -bis draft could be better named to imply it includes SOHO networks with internal routing, where cpe-router-07 implies there's no internal routing.   It's really a different scenario.

Tim

BTW the -bis draft currently contains a dangling 4193 entry in the bibliography, i.e. it says nothing about ULAs.

---

From: Rémi Després <[email-masked]>
Date: Tue, 14 Dec 2010 16:48:07 +0100

> the wide area routing system.

Indeed.
We want multihoming to work with PAs, with e2e transparency for referrals, and with ingress filtering compatibility.

In my understanding, sec. 3.3 of draft-despres-softwire-sam, does provide a breakthrough solution to the problem.
Yet, its visibility in IETF is still almost nil.
I hope Fred will read it, as he promised me in Beijing, and will react.

> PI + NAT66 = scalable multihoming without touching the wide area routing system.

One who has a PI prefix should IMHO take advantage of it by using his PI prefix internally, and thus have e2e transparency and ingress-filtering compatibility.

But not everyone WILL NOT have a PI prefix! 

RD

---

From: Rémi Després <[email-masked]>
Date: Tue, 14 Dec 2010 19:21:39 +0100

+1

---

From: Fred Baker <[email-masked]>
Date: Tue, 14 Dec 2010 10:25:32 -0800

So we have two that would like to pull the draft back to address this. Are there others?

---

From: Ole Troan <[email-masked]>
Date: Tue, 14 Dec 2010 21:45:15 +0100

Remi,

what exactly is it you would have changed in this draft?
(and no, I don't think SAM is within scope of this document, as multi-homing isn't).

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Wed, 15 Dec 2010 08:49:33 +0100

> what exactly is it you would have changed in this draft?

I confirm that I just want ULA support in CEs to be made optional, at least in residential CEs until implications on what should go with it are much better specified.

> (and no, I don't think SAM is within scope of this document, as multi-homing isn't).
Where did you see such a suggestion?
(This never came to my mind. I just mentioned SAM in a mail to Brian on the relationship he saw between PI prefixes and the need for NAT66.)

Cheers,
RD

---

From: Ole Troan <[email-masked]>
Date: Wed, 15 Dec 2010 08:56:56 +0100

Remi,

> I confirm that I just want ULA support in CEs to be made optional, at least in residential CEs until implications on what should go with it are much better specified.

understood. by "support" do you mean the "capability" or that the "default" shouldn't be on?

given the fact that any CPE have the capability to use a ULA prefix (e.g. manually configured treating it as a global), I would see it as more problematic for the co-existence case if we didn't specify text dealing with ULAs specifically.

we now also have the following proposed paragraph:

   ULA addressing is useful where the IPv6 CE router has multiple LAN
   interfaces with hosts that need to communicate with each other.  If
   the IPv6 CE router has only a single LAN interface (IPv6 link) then
   link-local addressing can be used instead.

cheers,
Ole

---

From: Randy Bush <[email-masked]>
Date: Wed, 15 Dec 2010 18:25:21 +0900

> So your solution to configuration of the router and local access in
> general is not IPv6, but IPv4. I'm listening for Randy's comment about
> IPv6 networks...

but you covered for me while i was flying.  thanks!

i don't know what all the fuss about ula is.  after all, rfc1918 has
never leaked.  </sarcasm>

there are one or more things really broken about this discussion.

randy

---

From: Rémi Després <[email-masked]>
Date: Wed, 15 Dec 2010 10:29:21 +0100

> understood. by "support" do you mean the "capability" or that the "default" shouldn't be on?

I mean "capability".
Vendors that sell CPEs intended for completely unmanaged operation should be *permitted* by IETF to dispense with ULA implementation, documentation, and after-sale support.
This of course doesn't prevent vendors addressing the same market to support ULAs in their products if they so prefer.
The market will decide.

> given the fact that any CPE have the capability to use a ULA prefix (e.g. manually configured treating it as a global), I would see it as more problematic for the co-existence case if we didn't spe…

Although I would be personally satisfied if the whole subject of ULAs would be left for a later version, I understand that enough people want to deal NOW with the subject NOW, and don't object.

>   link-local addressing can be used instead.

IMHO, this makes it insufficiently clear that vendors of unmanaged CPEs MAY dispense with ULA support, at least if they have only one LAN interface.

Cheers,
RD

---

From: Ole Troan <[email-masked]>
Date: Wed, 15 Dec 2010 11:02:22 +0100

Remi,

> Although I would be personally satisfied if the whole subject of ULAs would be left for a later version, I understand that enough people want to deal NOW with the subject NOW, and don't object.

both with revision 07 and if we took ULA out altogether, the effect would be the same. it would do nothing to resolve the coexistence problem.

cheers,
Ole

---

From: "t.petch" <[email-masked]>
Date: Wed, 15 Dec 2010 10:24:11 +0100

----- Original Message -----
From: "Fred Baker" <[email-masked]>
To: "IPv6 Operations" <[email-masked]>
Sent: Tuesday, December 14, 2010 7:25 PM

So we have two that would like to pull the draft back to address this. Are there
others?

Yes, withdraw.  There are too many proposed paragraphs swilling around for this
I-D to
be seen as rough consensus, IMHO.

Tom Petch

>>
>> The RFC Editor has this draft in the MISSREF state, because it still needs a
reference to I-D.ietf-6man-node-req-bis, which is still in active development.
There should still be plenty of time to withdraw this draft, revise it, and get
it back into the queue without causing any delay in the RFC publication
schedule.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Dec 2010 11:16:12 +1300

> This of course doesn't prevent vendors addressing the same market to support ULAs in their products if they so prefer.

And that's the problem. This is a case where there is no incentive for the
vendors to support ULA in low-end devices unless we make it a requirement,
and the low-end users won't know that they needed ULA until their
air conditioning subnet fails due to an ADSL outage causing their PA
prefix to expire.

So I think the capability should be a MUST with the default left up to
the vendor. (If we can't quickly resolve the coexistence issues, maybe the
default should be OFF initially.)

   Brian

---

From: Rémi Després <[email-masked]>
Date: Thu, 16 Dec 2010 11:56:33 +0100

> vendors to support ULA in low-end devices unless we make it a requirement,

If IETF makes rules that vendors have legitimate reasons not to comply with, this doesn't help.
It only increases defiance against IETF specifications, in particular concerning IPv6. 

> default should be OFF initially.)

By going too fast on some contentious subjects, one creates poor user experience that goes against the objective of promoting real IPv6 deployments with good user experience.

I don't know what what air conditioning devices do, but I would personally suggest that, for local communications, their products should:
- either run on their own local link (as some do in my understanding)
- and/or be dual stack (IPv4 with RFC 1918 remains a reliable way to communicate in case of ADSL outage).

IMHO, IETF will be responsible for many operational problems if, because dual stack has faced slow adoption, it now pushes for direct move to IPv6 only.

What is needed is NATIVE IPv6 ADDRESSES almost everywhere asap, without losing what can still work in IPv4. 
(In this respect the 6a44 approach we are together endeavoring to promote is on the right track.)

Regards,
RD

---

From: <[email-masked]>
Date: Thu, 16 Dec 2010 12:45:45 +0100

>>> Vendors that sell CPEs intended for completely unmanaged 
>operation should be *permitted* by IETF to dispense with ULA 
>implementation, documentation, and after-sale support.
>>> This of course doesn't prevent vendors addressing the same 
>market to support ULAs in their products if they so prefer.
>>> The market will decide.
>> 
>> And that's the problem. This is a case where there is no 
>incentive for 
>> the vendors to support ULA in low-end devices unless we make it a 
>> requirement,
>

If there are technical reasons the IETF must promote them, even if the vendors feelings are different.

>
>> and the low-end users won't know that they needed ULA until 
>their air 
>> conditioning subnet fails due to an ADSL outage causing their PA 
>> prefix to expire.
>> 
>
>> the vendor. (If we can't quickly resolve the coexistence 
>issues, maybe 
>> the default should be OFF initially.)
>
>By going too fast on some contentious subjects, one creates 
>poor user experience that goes against the objective of 
>promoting real IPv6 deployments with good user experience.

Use of ULA addressing is part of real IPv6 deployment. And with RFC3484bis "good" user experience will follow.

>
>I don't know what what air conditioning devices do, but I 
>would personally suggest that, for local communications, their 
>products should:
>- and/or be dual stack (IPv4 with RFC 1918 remains a reliable 
>way to communicate in case of ADSL outage).

So all future thin clients have to support IPv4 and cannot be implemented IPv6-only? Thats a show stopper for the evolving net of things and M2M communication IMHO.

best regards,
Christian Hahn
>
>IMHO, IETF will be responsible for many operational problems 
>if, because dual stack has faced slow adoption, it now pushes 
>for direct move to IPv6 only.
>
>What is needed is NATIVE IPv6 ADDRESSES almost everywhere 
>asap, without losing what can still work in IPv4. 
>>>> given the fact that any CPE have the capability to use a 
>ULA prefix (e.g. manually configured treating it as a global), 
>I would see it as more problematic for the co-existence case 
>if we didn't specify text dealing with ULAs specifically.
>>> 
>>> Although I would be personally satisfied if the whole 
>subject of ULAs would be left for a later version, I 
>understand that enough people want to deal NOW with the 
>subject NOW, and don't object.
>>> 
>>> IMHO, this makes it insufficiently clear that vendors of 
>unmanaged CPEs MAY dispense with ULA support, at least if they 
>have only one LAN interface.
>>> 
>>> Cheers,
>>> RD
>>> 
>>> 
>>>

---

From: Rémi Després <[email-masked]>
Date: Thu, 16 Dec 2010 15:42:45 +0100

Christian,

Thanks for your comments.
Further reactions below.

> If there are technical reasons the IETF must promote them, even if the vendors feelings are different.

Vendors that ignore technical reasons that are pertinent to their use case don't have "legitimate reasons" for what they do.
The point is that different use cases typically lead to different technical requirements.

> Use of ULA addressing is part of real IPv6 deployment.
> And with RFC3484bis "good" user experience will follow.

Like many other customers of free.com, I have been using native IPv6 since 2007 without suffering from the absence of ULAs.
This is real IPv6 deployment, with good user experience, and well before RFC3484bis is approved and widely supported.
My point is that such deployments shouldn't be made "illegal" by placing a MUST on a feature that isn' needed for them.

> So all future thin clients have to support IPv4 and cannot be implemented IPv6-only? Thats a show stopper for the evolving net of things and M2M communication IMHO.

For all "future" thin clients, NO.
In the short term, for thin clients intended to work on a large installed base of residential networks, YES.

Regards,
RD

---

From: Mark Townsley <[email-masked]>
Date: Thu, 16 Dec 2010 16:42:35 +0100

> My point is that such deployments shouldn't be made "illegal" by placing a MUST on a feature that isn' needed for them.

Knowing Free, if hi-fi equipment, or smart-meters, or baby monitors, or
DECT phones, or printers, or the wine cave thermometer, or whatever else
used ULAs in the home, they'd be happy to use them with their freebox as
well. I don't think they would care one way or another about a new MUST
in an RFC other than they would be happy to have a decision so that
hopefully interoperable open source would arrive to incorporate when
they get an available cycle to do so.

What they have been asking for from us though is a good document that
defines how to best do IPv6 routing in the home so they better know what
to do with that /60 they gave all of us.

- Mark

PS. And for my part I have an apple time capsule, apple express, Cisco
IOS router (for the corporate VPN), and linksys plugged into my freebox.
All are capable of v6. If I did have a v6 baby monitor, or a wifi
bathroom scale like Ole has, I'd like it to work even if the freebox was
down.

---

From: Rémi Després <[email-masked]>
Date: Thu, 16 Dec 2010 17:09:47 +0100

> I'm scratching my head here. Remi, are you arguing that the ability to *configure* a ULA as opposed to having the router generate it for itself means that sites are more likely to not have random p…

Yes, that was my point.
However, see below.

> To my way of thinking, the argument for making a ULA a /48 is to give the administration using the ULA the ability to configure 2^16 subnets within his network while having a prefix that is extreme…

Fair enough.
This is new argument for me, but I understand it. 

> Or, if I am misunderstanding your remark, help me out here?

Note that it was *only for ULAs* that I believed manual configuration had to be avoided in CEs. 
It was my understanding of RFC 4193.

With configurable ULA prefixes in CEs, many users may choose easily remembered values, e.g. fd00::/48. 
This is fine as far as I am concerned.

CONCLUSION: I no longer have remarks, or concerns, about ULA prefixes being configurable in CEs.
End of this particular discussion for me.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 17 Dec 2010 12:42:30 +0100

Fred,

It took me a few days to comment this detailed mail of yours but it hasn't been forgotten.
I hope you will find the conclusion constructive.

>  
> The other line of reasoning would suggest that networks will tend to prefer to configure-and-operate one technology or the other but not both, and will therefore in time squeeze the *use* of IPv4 out of their networks

There is I believe a third line of reasoning:
For IPv6 native addresses to be deployed rapidly, the short term target should remain the dual-stack service (be it across infrastructures that are partially single stack).

Aiming first at a dual-stack service was the original IETF approach.
in my understanding it remains the most practical one, and should still be encouraged.

> in the same way and for the same reason that they have delayed configuration of IPv6.

IMHO, the reason why IPv6 deployment has been, and still is, so slow is the vicious circle I described in RFC 5569: ISPs waiting for customer demand; customers waiting for applications that need IPv6; application vendors waiting for extensive ISP deployments by ISPs. 
As 6rd has shown, a dramatic reduction of ISP incurred costs to offer dual-stack service can, where it is applicable, break this vicious circle.

> Adding IPv6 support to an existing printer-or-whatever is a matter of a software update,

You rightly said "adding IPv6 support" (not "substituting IPv6 support to that of IPv4").

> or (if my experience with printers is anything to point to) to watch them die their usual untimely death and replace them with equipment that supports IPv6 (which is why my printer supports IPv6).

> That second line of reasoning would actually suggest that once we reach the tipping point - once traffic is O(50%) IPv6, half-or-more of deployed equipment is IPv6-capable, and content is generally available on IPv6, gravity will pull in the direction of IPv6, and will have as strong an attraction as IPv4 had a year ago - and growing. One could easily imagine as early as 2013 or 2014 people asking a very serious question as to whether it is yet time to shut down IPv4.

I see a shut down of the dual-stack SERVICE as early as in 2013 or even 2014 as an *unnecessary frightening* idea.

With more and more dual-stack service available, and with more and more servers and peers having it, the proportion of IPv6 traffic will automatically increase, which is what we want.
There is no need for this to hastily break an IPv4 connectivity that a significant number of customers are still depending on.

> As a vendor, I can tell you that access ISPs as a class are having "interesting times". The Cable Modem networks are moving in the direction of DOCSIS 3.0 and IPv6 deployment, as Comcast has made very public. Some are using 6rd in the near term to work around existing DOCSIS 2.0 deployment; every one I have spoken with expects to have dual-stack deployment in the not-to-distant future,
> and expects IPv6-only at some point in the future.

We agree that the service is likely to become IPv6-only "in the future", but with uncertainty as to when. 
We also agree that there will soon be more and more IPv6-only ROUTING INFRASTRUCTURES.
THis isn't a reason, though, to hastily disrupt the dual-stack SERVICE.
 
BTW, dual-stack-service continuity across an IPv6-only routing infrastructure is the reason why 4 Japanese ISPs announced plans to use 4rd.
I hope IETF will soon find a place where 4rd can be worked on.
(Why not in v6ops, now that it has been declared out of scope in Softwire?)

> The DSL networks I am speaking with have a problem in their access path; some of the equipment is difficult to upgrade and is IPv4-only. Many are talking about a dual-stack core with a 6rd path over the troublesome access equipment; at least two are talking about literally replacing the IPv4 networks with IPv6 and running IPv4 as an overlay - ds-lite. For them, there is also a technology question: would it make more sense to stay with DSL technology with its speed and distance limitations, or while changing out the access path change out the last mile to fiber-to-the-<something>?

Where hardware doesn't support IPv6, the 6rd of RFC 5969 is as you know a simple approach to rapidly offer native IPv6 where CPEs can't be upgraded.
 
> Before you say "no brainer", follow the money. I'm not hearing consensus, but I am hearing the question.

No intention to say "no brainer" ;-).
Just let me note that, to "follow the money", where rather inexpensive solutions are applicable to satisfy significant customer needs they shouldn't be neglected (6rd, 4rd, 6a44 are designed to be in the category).

> In writing a specification like this, I think we have to make educated guesses about the future, and make statements that we can support now and expect to be able to continue to support several years hence. Usually, when we have written such (RFCs 1122/1123, 1812, 4294), we have been able to assume that present status/practice was a good indicator of future status/practice; in this case, both lines of reasoning say that present practice (IPv4-only networking for the most part) is absolutely *not* a prediction of the future,

We completely agree that there will be more and more IPv6-only routing networks.
As a matter of fact, 4rd is designed to maintain IPv4 residual connectivity across them.

> and the question is whether the medium term will be more predominantly IPv4+IPv6 or IPv6-only. We have to believe that in the long term (a decade out), IPv6-only networks will be increasingly prevalent, especially given that we have some now.

This is one more instance where distinguishing between IPv6-only "routing networks" and IPv6-only "service" is useful.

> Game theory tells me to choose strategies that give me lots of options, so that I can adapt to circumstances that change in the course of play.

So do I (assuming of course we talk about options that aren't having the same purpose) 
 
As a matter of fact, this why I argue against putting a MUST on a CPE feature that isn't present in CPEs that successfully offer the dual-stack service today.
This limits the number of options left to CPE vendors and operators.

> In chess, one would talk about controlling the center of the board. Choosing a course of action that optimizes for one possibility but not another works against me if the other becomes reality. If in the long term IPv4 is going to be a headache and the issues are more readily solved using a ULA, then in the long term I want the option of turning off IPv4 and using a ULA.

Wanting "the option" isn't a reason to make the feature a MUST.
Vendors of firewalls appear to promote the use of NATs in IPv6, but at least some vendors of unmanaged networks may have a different logic.

(BTW, don't you believe that CPEs that have ULAs activated will tend to have some sort of IPv6 NATs also activated?
I wonder what Randy has to say about it!)

> If in the medium term I might be able to use existing IPv4 configurations or the situation might be as in the long term, then providing the ability to use IPv4 *or* a ULA makes sense. Requiring me to use IPv4 for those circumstances primarily guarantees that the specification will be obsolete in the long term, and runs the risk of it being obsolete in the medium term.

I don't suggest to use IPv4 between hosts that have e2e IPv6 service!

> Given that context, I don't see why we would not RECOMMEND (in cpe-router-bis) that CPE routers have the *capability* of doing the math to generate a ULA, for the purposes of configuring an interfa…

CONCLUSION: although I believe a MAY would be more appropriate, I could join a consensus where the ULAs you wish to "RECOMMEND" would have a SHOULD in cpe-router-bis.
Would this be acceptable?

Regards,
RD

---

From: Fred Baker <[email-masked]>
Date: Fri, 17 Dec 2010 05:51:09 -0800

> in my understanding it remains the most practical one, and should still be encouraged.

We seem to be talking about two separate things here. I am trying to predict the future, which has all the issues of crystal-ball-gazing. You're trying to set a policy - "should". I would agree that the direction the IETF should be recommending to operators is some variation on dual stack. At Starbucks, the IETF's advice plus five dollars will get you a four dollar cup of coffee.

> There is no need for this to hastily break an IPv4 connectivity that a significant number of customers are still depending on.

OK, no problem. I like dual stack service. Can you tell me why operators I am talking with are so very sure they want to get to a single stack, then?

> (Why not in v6ops, now that it has been declared out of scope in Softwire?)

In v6ops, it would be declared out of scope and sent to softwire, like 6rd was and for the same reason. We have had this discussion.

> Would this be acceptable?

I suspect that is ULA-1 in draft-ietf-v6ops-ipv6-cpe-router; the text we agreed on a long time ago says that the router MUST be capable of generating a ULA, but should only do so if told to. http://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6-cpe-router-08.txt

---

From: <[email-masked]>
Date: Fri, 17 Dec 2010 14:46:18 +0100

Hi Remi,

please see inline ...

>poor user 
>>> experience that goes against the objective of promoting real IPv6 
>>> deployments with good user experience.
>> 
>Like many other customers of free.com, I have been using 
>native IPv6 since 2007 without suffering from the absence of ULAs.
>This is real IPv6 deployment, with good user experience, and 
>well before RFC3484bis is approved and widely supported.
>My point is that such deployments shouldn't be made "illegal" 
>by placing a MUST on a feature that isn' needed for them.
I don't ment to say that we need a MUST here, but I would like to see a SHOULD here. I don't think we should force user to deploy there home networks with only one link (and LL) if they would like to have IPv6 working even if the WAN link is down.

>>> I don't know what what air conditioning devices do, but I would 
>>> personally suggest that, for local communications, their products 
>>> should:
>>> - and/or be dual stack (IPv4 with RFC 1918 remains a 
>reliable way to 
>>> communicate in case of ADSL outage).
>> 
>> So all future thin clients have to support IPv4 and cannot 
>be implemented IPv6-only? Thats a show stopper for the 
>evolving net of things and M2M communication IMHO.
>
>In the short term, for thin clients intended to work on a 
>large installed base of residential networks, YES.
I expect these class of thin clients to have a longer lifetime then common home network equipment. So short term could be easily change to long term here ...

cheers,
Christian Hahn

>
>Regards,
>RD
>
>
>> 
>> best regards,
>> Christian Hahn
>>> 
>>> IMHO, IETF will be responsible for many operational problems if, 
>>> because dual stack has faced slow adoption, it now pushes 
>for direct 
>>> move to IPv6 only.
>>> 
>>> What is needed is NATIVE IPv6 ADDRESSES almost everywhere asap, 
>>> without losing what can still work in IPv4.
>>> ULA prefix (e.g. manually configured treating it as a global), I 
>>> would see it as more problematic for the co-existence case if we 
>>> didn't specify text dealing with ULAs specifically.
>>>>> 
>understand that 
>>> enough people want to deal NOW with the subject NOW, and don't 
>>> object.
>>>>> 
>>> unmanaged CPEs MAY dispense with ULA support, at least if they have 
>>> only one LAN interface.
>>>>> 
>>>>> Cheers,
>>>>> RD
>>>>> 
>>>>> 
>>>>>

---

From: Rémi Després <[email-masked]>
Date: Fri, 17 Dec 2010 15:36:30 +0100

> I expect these class of thin clients to have a longer lifetime then common home network equipment.

Indeed, at least for some of them.

> So short term could be easily change to long term here ...

Supporting both IPv4 and IPv6 NOW will NOT PREVENT any thin client to still work IN THE LONG TERM (when only the IPv6 service remains). 

A device that has to work on a large installed base of residential networks in the long term and ALSO in the short term should therefore support both IPv6 AND IPv4.
Right?

RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 17 Dec 2010 18:13:22 +0100

Hi, Mark,

If the DSL access of a Freebox is down, the Freebox still advertises the public prefix it had before the break.
Ole's device would therefore continue to work in IPv6 even in this case.
(And, of course, if the Freebox is completely down, whether it does ULAs or not is irrelevant.)

I therefore still believe that the wonderful Freeboxes that both of us have at home shouldn't be considered illegal by IETF.

Without feeling an obligation to support ULAs, Free.com has made the earliest large scale deployment of the native IPv6 service.
IMHO, such initiatives should rather be encouraged than declared illegal.

Regards,
RD

---

From: Fred Baker <[email-masked]>
Date: Fri, 17 Dec 2010 09:22:56 -0800

> If the DSL access of a Freebox is down, the Freebox still advertises the public prefix it had before the break.

What does it use before it has ever connected to Free?

> I therefore still believe that the wonderful Freeboxes that both of us have at home shouldn't be considered illegal by IETF.

I realize that English is not your first language. Let me help you out with the definition of a word.

Something is "illegal" if it is "contrary to or forbidden by law". Nobody's making a law against Free boxes. But just as there were routers before RFC 1812 was written and RFC 1812 was subsequently specified by the IETF, this document says what we as a group think CPE routers should have as capabilities and services. A CPE Router that doesn't meet the specification is not prevented from being used. It is something we are saying is good but not the best.

---

From: Rémi Després <[email-masked]>
Date: Fri, 17 Dec 2010 18:52:28 +0100

> What does it use before it has ever connected to Free?

The CPE is provided by Free and has its updated software downloaded via the DSL access, via which it gets also an IPv6 prefix.

> Something is "illegal" if it is "contrary to or forbidden by law". Nobody's making a law against Free boxes. But just as there were routers before RFC 1812 was written and RFC 1812 was subsequently specified by the IETF, this document says what we as a group think CPE routers should have as capabilities and services.

If routers "should have" ULAs, a SHOULD in the document should be OK.

RD

---

From: Mark Townsley <[email-masked]>
Date: Fri, 17 Dec 2010 18:53:42 +0100

> If the DSL access of a Freebox is down, the Freebox still advertises the public prefix it had before the break.

Yes, of course, until the prefix lifetime expires at least.

> (And, of course, if the Freebox is completely down, whether it does ULAs or not is irrelevant.)

Perhaps I connect it to my linksys instead, and never connect it to my
Freebox. Perhaps there are ethernet ports in the back of my hifi that
connects all the hifi equipment together (sure makes more sense than
separate optical, HDMI, etc. cables)... and later I connect it to my
network so that I can stream online radio, etc..

Point is, if we are building the basis for the home network over the
next 30 years, I'd rather keep the ability to have routed networks that
are not dependent on a global address from an ISP on every link. Also,
I'd like some devices to be to have addresses that do not change, and
are not reachable on the global internet.

> IMHO, such initiatives should rather be encouraged than declared illegal.

I really don't think updating an IETF document makes our deployments
"illegal" - but this is probably just unfortunate word choice.

I think Free would agree that we need to make the right architectural
choice, encourage implementation, and they will be happy to update their
code accordingly when the time is right.

- Mark

---

From: Fred Baker <[email-masked]>
Date: Fri, 17 Dec 2010 09:56:53 -0800

> If routers "should have" ULAs, a SHOULD in the document should be OK.

My understanding of the discussion on this list: routers "SHOULD" have the ability to generate a ULA (eg, perform the random number trick) when triggered to do so. They "MUST" be configurable with an RFC 4291-compliant unicast prefix, of which a ULA is an example.

---

From: Rémi Després <[email-masked]>
Date: Fri, 17 Dec 2010 19:28:34 +0100

Le 17 déc. 2010 à 18:53, Mark Townsley a écrit :

> "illegal" -

> but this is probably just unfortunate word choice.

I suppose that, knowing that my English is limited, "illegal" could have been understood as meaning "lacking a feature that an IETF endorsed RFC says the device MUST have" 

> code accordingly when the time is right.

Before this time is right, saying that CEs SHOULD have ULAs should be IMHO a better choice than saying it with a MUST.
Thus Freeboxes wouldn't be missing a feature said by IETF to be a MUST.

RD

---

From: Mark Townsley <[email-masked]>
Date: Fri, 17 Dec 2010 21:30:45 +0100

On 12/17/10 7:28 PM, Rémi Després wrote:

> Thus Freeboxes wouldn't be missing a feature said by IETF to be a MUST.

Running-code is important, so learning from Free's deployment is important.

The freeboxes are ahead of the v6 game here, as such they really are not
the target of this doc. The target of this doc are people who are
writing code now, or that will be over the next few years. Further, I
think it is perfectly fine for a deployment that shipped in 2007 and
hasn't really changed since to be a little "out of date" when a document
appears in 2011.

So, let's both stop short of supposing what Free would and would not be
concerned about in terms of IETF compliance with this doc. If they want,
they can jump in and let us know themselves.

- Mark

---

From: "STARK, BARBARA H (ATTLABS)" <[email-masked]>
Date: Fri, 17 Dec 2010 16:12:03 -0500

IMO, a CE (Consumer Electronics) Router is not the same thing as an
ISP-provided consumer-grade router. The idea that the IETF's
informational CE Router requirements must be 100% applicable to
ISP-provided consumer-grade routers is not something I agree with.

Any idea that ISPs must feel obligated to abide by all recommendations
in an informational RFC intended for CE Routers, when designing their
own ISP-provided consumer-grade routers, is, to me, heresy. I'm
horrified to think that any ISP should feel somehow *obligated* to abide
by the recommendations of an informational RFC. If an ISP's customers
are happy with what they get, then it must be right. [Similarly, if a
manufacturer's customers are happy with what they get, then the product
must be right -- for example, if "the industry" were to recommend that
batteries be replaceable in portable devices, and a manufacturer chose
to sell a device where the battery was not replaceable and would die
after 18 months, but customers kept buying the device, then the
manufacturer's decision must have been right. So manufacturers of CE
routers shouldn't feel obligated to follow informational
recommendations, either.] Informational recommendations have no power
until or unless potential purchasers/customers become aware of the
recommendation and decide they want what it recommends. 

While consumer expectations for the two are very similar, I do not
believe they are identical. For example, I do not believe that consumers
necessarily believe that they can set up permanent stand-alone (no WAN
connection) home networks using ISP-provided consumer-grade routers. I
believe consumers do have this expectation of CE routers.

Furthermore, the idea that an informational RFC should be written so as
to be backward-compatible with existing implementations, so these
exiting implementations can retroactively claim compliance, is something
I strongly disagree with. I'm vehemently opposed to that idea.

Because I believe this informational document should stand the test of
time (long beyond an initial transition period), and because I believe
that a significant number of consumers have the expectation that they
can create a fully functional, stand-alone home network (now and in the
future), I believe the ability to generate ULA prefixes is required. 

However...
While I do not think that backward-compatibility with existing
implementations is a valid reason for not requiring an expected
capability, I am very open to the following arguments:
 1. It adds considerable complexity (which implies cost).
 2. There's a strong likelihood that the capability will be improperly
implemented.

I'm not convinced that either of these is true for the ability to
generate ULA prefixes.

But if there is strong desire to back off to a "should" (which is
stronger than "may", notwithstanding suggestions to the contrary), then
I won't argue too hard. Realistically, while I would like to see this
document stand the test of time, I think it's more likely that we'll
revise it in a couple of years and obsolete the current version, once we
know better how the future really does turn out. 
Barbara

---

From: <[email-masked]>
Date: Mon, 20 Dec 2010 09:22:52 +0100

Hi Rémi,

please see inline ..

>>> be implemented IPv6-only? Thats a show stopper for the evolving net 
>>> of things and M2M communication IMHO.
>>> 
>>> In the short term, for thin clients intended to work on a large 
>>> installed base of residential networks, YES.
>
>> I expect these class of thin clients to have a longer 
>lifetime then common home network equipment.
>
>Supporting both IPv4 and IPv6 NOW will NOT PREVENT any thin 
>client to still work IN THE LONG TERM (when only the IPv6 
>service remains). 
>
>A device that has to work on a large installed base of 
>residential networks in the long term and ALSO in the short 
>term should therefore support both IPv6 AND IPv4.
>Right?
Yes, but this was'nt my point. My point was that we should not *mandate IPv4* for future thin clients.

cheers,
Christian

---

From: Rémi Després <[email-masked]>
Date: Mon, 20 Dec 2010 10:32:21 +0100

> ISP-provided consumer-grade routers is not something I agree with.

In this draft, CE refers to Customer Edge, not Consumer Electronics.
It covers ISP-provided CE's which aren't consumer electronics you buy in shops.

> ...
> I am very open to the following arguments:

I agree that ULAs may not introduce "considerable complexity", but they introduce non negligible operational complexity:
- ULAs will in practice imply some forms of NAT66 
- NAT66 breaks the killing advantage of IPv6 (each host has a global address that it sees at its local interface)
- NAT66 has two main variants (the stateless NPTv6, and the stateful NAPT66), none of which has a stabilized specification yet.

> I won't argue too hard.

"SHOULD" is a reasonable compromise.
Let's hope it can be recognized as such.

> Realistically, while I would like to see this

Regards, 
RD

---

From: Ole Troan <[email-masked]>
Date: Mon, 20 Dec 2010 10:51:02 +0100

Remi,

[...]

> - NAT66 has two main variants (the stateless NPTv6, and the stateful NAPT66), none of which has a stabilized specification yet.

I don't see the logical implication of ULA requiring IPv6 NAT. please explain.

cheers,
Ole

---

From: [email-masked]
Date: Mon, 20 Dec 2010 10:53:50 +0100 (CET)

> It covers ISP-provided CE's which aren't consumer electronics you buy in shops.

There are plenty of service providers using a service model where the
customer can supply the router. In other words, I don't believe there
is universal agreement that a Customer Edge router necessarily means
that the router is provided by the ISP.

http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-08

in chapter 2, Terminology, simply says "The IPv6 CE router connects
the end-user network to a service provider network."

If "provided by the ISP" is the intention of the authors then this 
should be explicitly spelled out.

Steinar Haug, Nethelp consulting, [email-masked]

---

From: Ole Troan <[email-masked]>
Date: Mon, 20 Dec 2010 10:56:33 +0100

Steinar,

[...]

> should be explicitly spelled out.

no, it is not. although CableLabs and BBF are writing recommendations for SP provided / managed CPEs, I expect this document to apply to all cases. and we have tried to avoid any conflicts with existing BBF and CableLabs CPE specifications.

cheers,
Ole

---

From: Fred Baker <[email-masked]>
Date: Mon, 20 Dec 2010 09:01:02 -0800

On Dec 20, 2010, at 12:22 AM, <[email-masked]> wrote:

> My point was that we should not *mandate IPv4* for future thin clients.

On that, I agree.

---

From: Rémi Després <[email-masked]>
Date: Mon, 20 Dec 2010 18:21:31 +0100

Ole,

> I don't see the logical implication of ULA requiring IPv6 NAT. please explain.

1.
Well, I didn't mean that it was a "logical" implication.
I expressed a concern about a direction that seems to be be followed.

For example, draft-mrw-nptv6-01 says (asterisks added): "All of the hosts on the internal network will use *addresses from a single, locally-routed prefix*, and those addresses will be translated to/from addresses in a globally-routable prefix as IP packets transit the NPTv6 Translator."

I do understand that, even if NPTv6 is endorsed (and/or some other form of NAT66), not all customers will want to activate ULA+NAT66, but I foresee that the pressure will be high to have NAT66 in all user provisioned CPEs. 

That said, I am ready to accept that I may be too pessimistic on this point, and there are arguments in favor of ULAs that are on a different ground.

2.
Then let's be practical:

Where we have:  
"L-1:   The IPv6 CE router MUST support ULA addressing [RFC4193]."

I propose something like:
"L-1:   A CE router SHOULD support the ULA addressing of [RFC4193]. If it doesn't, it MUST advertise an IPv6 prefix on each of its LAN interfaces even when none of its WAN interfaces is operational.  These prefixes MAY be either those last used before the complete WAN interface failure, or some ULA-like constant values (e.g. fd01::/48, fd02::/48...)".

- This satisfies the need that IPv6 still works without WAN access (indeed important).
- This doesn't exclude the behavior of CPEs that, for several years now, have successfully worked in IPv6.

Cheers,
RD

---

From: Fred Baker <[email-masked]>
Date: Mon, 20 Dec 2010 09:43:22 -0800

> For example, draft-mrw-nptv6-01 says (asterisks added): "All of the hosts on the internal network will use *addresses from a single, locally-routed prefix*, and those addresses will be translated t…

I think you're referring to 

http://tools.ietf.org/html/draft-mrw-nat66
  "IPv6-to-IPv6 Network Prefix Translation", Margaret Wasserman, Fred
  Baker, 16-Dec-10

Yes, I changed the acronym to nptv6 in the document, but I didn't change the moniker. 

Within such a network, yes, I would expect people to use a ULA, in order to maximize their address independence. I would be very hesitant to describe that document in any sentence that used the word "consensus". It is a consensus between Margaret and I; as near as I can tell everyone in the IETF dislikes what stateful IPv4/IPv4 NAT has done in the Internet (see RFC 2993), and therefore dumps on stateless network prefix translation without reading the document. We had a BOF for the purpose of discussing it two years ago, and not only did the concept not get discussion - the agenda was pre-loaded with unrelated discussions including a discussion of 6rd, plus an IAB comment on the concept of a stateful IPv6/IPv6 NAT, and the lengthy line consisted of people arguing against stateful IPv6/IPv6 NAT and didn't respond to Margaret's presentation - but people barely let Margaret present her topic. I don't think it has had an open-minded hearing in the IETF. 

> That said, I am ready to accept that I may be too pessimistic on this point, and there are arguments in favor of ULAs that are on a different ground.

ULAs were not designed to live behind a network prefix translator. They were designed to be a prefix one could use within a local network. I'm not sure there is a valid line between the dots you're connecting.

> - This doesn't exclude the behavior of CPEs that, for several years now, have successfully worked in IPv6.

As I have noted before, the word "support" here is highly ambiguous.

I would hope that any CPE Router would be configurable with any RFC 4291-compliant address. A ULA is an example of such. If, given a valid address, you can't configure a router to use it, you have a broken router. Speaking as a vendor, when you tell me that a router should be able to "support" an address of a certain type, I conclude that you want it to be configurable with that style of address and able to use it appropriately in routing. The document already says that.

The discussion on the list has been about 
1) whether the router should be able to *generate* a ULA, which is to say whether the router can obtain its date/time settings in NTP format and do a certain bit of arithmetic with the result as a seed, 
2) whether it should generate it automatically, and 
3) whether having don so it should automatically start advertising it in routing and in router advertisements. 

The outcome, to my knowledge, has been that

    - a CPE router SHOULD (not "MUST") be able to generate such a prefix
    - it SHOULD NOT do so automatically, but should do so on command
    - it should only include it in routing if so commanded

With the possible exception of a single word (SHOULD/MUST in ULA-1), the document says that, as I read it.

This horse is dead. Has actually been dead for a while. Can we stop beating it?

---

From: Rémi Després <[email-masked]>
Date: Mon, 20 Dec 2010 22:47:54 +0100

> This horse is dead. Has actually been dead for a while. Can we stop beating it?

If ULA-1 becomes "The IPv6 CE router SHOULD be capable of generating a ULA prefix [RFC4193]", this is good enough to cover my point.
If you are confirming that this will be the case, I am glad to add a +1 to the expressed approvals of the document.

Regards,
RD

---

From: Fred Baker <[email-masked]>
Date: Mon, 20 Dec 2010 13:54:10 -0800

That's the difference between -08 and -09. But now others are commenting.

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 24 Dec 2010 14:21:52 -0800

On 12/13/10 10:37 AM, james woodyatt wrote:
>> If you want to change with the draft says in a material way, I
>> would suggest putting whatever updates you want into
>> cpe-router-bis.
> 
> Unless I completely fail to understand the state of play here, the
> need for rough consensus passed a long time ago, when I wasn't paying
> particularly close attention to the progress of this draft.  I am
> quite surprised that nobody else noticed the coexistence problem
> until the draft proceeded to the RFC Editor and implementations
> started showing up in the real world.  The only way now to prevent
> the coexistence problem that concerns me is for the authors of the
> draft to withdraw it back into the working group.  That's what I'm
> making a public plea for them to do.
> 
> If the authors won't withdraw the draft, then I'm sure the
> coexistence problem will be addressed some other way, most likely by
> major content providers pushing back their IPv6 production schedules
> until enough hosts have been upgraded or retired that the damage to
> their IPv4 service at broken hosts will be acceptable to them.  Which
> they already seem to be doing, anyway, so maybe it doesn't matter.

No change you make at the moment or in the immediate future is going to
alter the installed base.

We have to live with the fact that the document authors, the reviewer's
, the implmentors and so forth live in am imperfect universe.

---

From: Joel Jaeggli <[email-masked]>
Date: Sat, 25 Dec 2010 11:56:50 -0800

> So we have two that would like to pull the draft back to address

w.g. chair hat off

it's worth observing that the next time it passes consensus, cruises
through the iesg, and arrives at this point that it will still be full
of problems.

the surface area of the problem of how cpe evolve and uptake ipv6
support is simply too large to produce a near perfect outcome.

imho pulling it back is arguably less useful than commencing work on the
next iteration or a bis document because this is not hardly the sole
facet of this document which is either incomplete or with which fault
can be found.

>>>> In that case, I for one want to see a complete draft I can run
>>>> through rfcdiff; this is too substantive for an editorial
>>>> AUTH48 fix.
>>> 
>>> The RFC Editor has this draft in the MISSREF state, because it
>>> still needs a reference to I-D.ietf-6man-node-req-bis, which is
>>> still in active development.  There should still be plenty of
>>> time to withdraw this draft, revise it, and get it back into the
>>> queue without causing any delay in the RFC publication schedule.
>>> 
>>> 
>>> _______________________________________________ v6ops mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>> 
>>