Subject: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-09.txt

From: [email-masked]
Date: Mon, 20 Dec 2010 10:00:02 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations Working Group of the IETF.

	Title           : Basic Requirements for IPv6 Customer Edge Routers
	Author(s)       : H. Singh, et al.
	Filename        : draft-ietf-v6ops-ipv6-cpe-router-09.txt
	Pages           : 18
	Date            : 2010-12-20

This document specifies requirements for an IPv6 Customer Edge (CE)
router.  Specifically, the current version of this document focuses
on the basic provisioning of an IPv6 CE router and the provisioning
of IPv6 hosts attached to it.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-cpe-router-09.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Dec 2010 08:06:44 +1300

Hang on.

> ULA-1: The IPv6 CE router SHOULD be capable of generating a ULA	
> prefix [RFC4193].

I don't remember a consensus call that we'd agreed to change
this to a SHOULD and I don't agree with it. It's well known
that cheapskate product managers use SHOULD as an excuse to
avoid implementing stuff. The compromise I thought we'd agreed
to was MUST implement but no default on/off.

I don't want to buy a supermarket CPE five years from now and
find that it doesn't support ULA despite claiming conformance
to RFC mumble.

Regards
   Brian Carpenter

---

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

I started a consensus call on -08 a week ago, and this has been the discussion since.

Yes, folks ignore shoulds. They also ignore entire documents.

On Dec 20, 2010, at 11:06 AM, Brian E Carpenter wrote:

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

---

From: Tim Chown <[email-masked]>
Date: Mon, 20 Dec 2010 20:09:39 +0000

> find that it doesn't support ULA despite claiming conformance

I'm also confused why the MUST for ULA-1 has become a SHOULD between -08 and -09 versions.

Tim

---

From: james woodyatt <[email-masked]>
Date: Mon, 20 Dec 2010 12:35:25 -0800

> I'm also confused why the MUST for ULA-1 has become a SHOULD between -08 and -09 versions.

I would not object to changing the SHOULD back to a MUST.

However, I will say that if IETF does so, then it will make the document that much easier for certain product managers I know to completely disregard the whole set of recommendations altogether, rather than simply disregard only the SHOULD recommendations which don't make any sense for them.

The draft currently has informative text explaining why some IPv6 CE routers have no practical need for this feature.  The text of ULA-1 now contains the correct normative language to match the new informative text.

That said, if for the sake of ideological purity we need to change this from SHOULD back to MUST, then I won't object so long as the informative text is changed to explain why even the IPv6 CE routers that have only one LAN interface, or that do not permit forwarding between multiple LAN interfaces, MUST also support ULA addressing.

I do not have any text to propose that would go to explaining that.  Indeed, I cannot see any explanation that would make sense to my product managers.

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

---

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

James,

> I do not have any text to propose that would go to explaining that.  Indeed, I cannot see any explanation that would make sense to my product managers.

Because a (best) current practice might emerge in which local devices are
always addressed using a ULA prefix, and link-local is confined to
use as a bootstrap prefix during a LAN cold start. If a site with
a single-interface CPE router chooses to upgrade to a multi-interface
router, they would not need to change their addressing practice.
(And they might choose to retain the same ULA prefix by manual config.)

Needless to say this also requires proper support of prefix delegation.

I don't think it's for us or for CPE vendors to prejudge what current
practice is going to be a few years from now, so we shouldn't close doors.

Oh, a possible compromise would be:

ULA-1: The IPv6 CE router MUST be capable of generating a ULA	
prefix [RFC4193], unless the router has exactly one client-side
routed LAN interface.

But I have some problems with that for the reasons stated above.
Incidentally, that has led me to a quibble with this text:

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

Shouldn't that be "multiple routed LAN interfaces"? The argument
doesn't apply to bridged interfaces, which is what most cheap
supermarket CPEs have.

    Brian

---

From: james woodyatt <[email-masked]>
Date: Mon, 20 Dec 2010 14:31:34 -0800

On Dec 20, 2010, at 13:10, Brian E Carpenter wrote:
> use as a bootstrap prefix during a LAN cold start.

One of the things about IPv6 link-local addresses that makes them better suited for use with mDNS than global scope addresses is that the reverse DNS mapping domains are naturally handled by mDNS, whereas the reverse DNS mapping domains for the ULA prefix this draft requires will not be populated by any content servers outside the local network.  Pity this draft doesn't recommend bundling a DNS content server into IPv6 CE routers...

---

From: Fred Baker <[email-masked]>
Date: Mon, 20 Dec 2010 14:33:30 -0800

Excellent thing to discuss in cpe-router-bis.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Dec 2010 11:49:39 +1300

> Excellent thing to discuss in cpe-router-bis.

I agree. Some form of local DNS support has come up on the [email-masked]
list as a useful direction to discuss. In fact, ULAs make it almost
unavoidable, I must admit.

   Brian

---

From: Fred Baker <[email-masked]>
Date: Mon, 20 Dec 2010 14:55:17 -0800

> unavoidable, I must admit.

The use of link-locals doesn't, of course :-)

---

From: james woodyatt <[email-masked]>
Date: Mon, 20 Dec 2010 14:59:02 -0800

> Excellent thing to discuss in cpe-router-bis.

Absolutely.  Because the next scarf to come out of my sleeve will be the one about a DNS resolving server to enforce the split horizon between the local network and the exterior enclaves; otherwise, you can't get the delegation from d.f.ip6.arpa to work for your ULA prefix.  Then we can start talking about dynamic DNS update servers.  Followed by the inevitable discussion about *securing* the DDNS service and bootstrapping the authorization for hosts to update their AAAA records in the DNS.

We can do this all day.  In the meantime, aren't you all glad that mDNS-SD and IPv6-LL just works* out of the box, today, without all that fuss?

[*] modulo the discussion in the security considerations section of the mDNS draft.

---

From: Fred Baker <[email-masked]>
Date: Mon, 20 Dec 2010 15:04:59 -0800

On Dec 20, 2010, at 2:59 PM, james woodyatt wrote:

> In the meantime, aren't you all glad that mDNS-SD and IPv6-LL just works* out of the box, today, without all that fuss?

If I have an extremely limited network, completely unlike the one in my home, yes. Would that it were actually useful.

---

From: Rémi Després <[email-masked]>
Date: Tue, 21 Dec 2010 11:02:40 +0100

> unavoidable, I must admit.

I se this as one more reason for a SHOULD to be wiser than a MUST.

Now, a proposal:
"ULAL-1:   The IPv6 CE router SHOULD be capable of generating a ULA prefix [RFC4193]. If it doesn't, it MUST advertise an IPv6 prefix on each of its LAN interfaces even when its WAN interfaces is not operational.  These prefixes MAY be either those last used before the WAN interface failure, or some ULA-like constant values (e.g. fd01::/48, fd02::/48...)."

regards,
RD

---

From: Ole Troan <[email-masked]>
Date: Tue, 21 Dec 2010 11:20:01 +0100

Remi,

> "ULAL-1:   The IPv6 CE router SHOULD be capable of generating a ULA prefix [RFC4193]. If it doesn't, it MUST advertise an IPv6 prefix on each of its LAN interfaces even when its WAN interfaces is n…

I think you may have a different operational model in mind that what is written down in the draft.  if a ULA prefix is used it would coexist with a global prefix on the link. you wouldn't add or withdraw ULAs depending on the existence of a global prefix.

in any case I would encourage you to take more complicated scenarios to the bis draft.

cheers,
Ole

---

From: Tim Chown <[email-masked]>
Date: Tue, 21 Dec 2010 10:22:48 +0000

> "ULAL-1:   The IPv6 CE router SHOULD be capable of generating a ULA prefix [RFC4193]. If it doesn't, it MUST advertise an IPv6 prefix on each of its LAN interfaces even when its WAN interfaces is n…

I think there's some confusion here.    The MUST is that CE is able to *generate* a randomised ULA prefix as per RFC4193.    ULA-1 isn't about what is advertised.   Indeed the default for whether ULAs are advertised or not is not prescribed in the text. 

The alternative if the CE is not able to generate such a prefix is that the administrator/user generates their own ULA prefix.    And then we know most will just use fd00::/48 or something like fd12:3456:7890::/48, which isn't compliant with ULAs as defined in RFC4193 section 3.2.   

The trick is to avoid exposing IPv6 literals to administrators/users as far as possible so they don't feel the need to use fd00::/48 just because it's easy.   But that's something for the Advanced -bis draft I guess.

Tim

---

From: Mark Smith <[email-masked]>
Date: Tue, 21 Dec 2010 21:36:40 +1030

On Mon, 20 Dec 2010 15:04:59 -0800

> If I have an extremely limited network, completely unlike the one in my home, yes. Would that it were actually useful.

I've just worked out that the implemenation of mDNS that I'm using in
my Linux only environment isn't setting the sin6_scope_id in the
sockaddr_in6 structure that getaddrinfo() returns for LL addrs. While
that may be a bug, the problem disappears once I announce a ULA prefix
in RAs, removing the ambiguity of out which interface an address
exists. ULAs can also usefully be in unicast DNS, where as I don't
think LLs could be - how would sin6_scope_id be set correctly? The
interface(s) a unicast DNS query traverses isn't necessarily going to
be the one(s) where the returned LL addr exists.

Regards,
Mark.

---

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

Hello, Tim,

The purpose of the proposal is to clarify that, even with a SHOULD in ULA-1, CPEs have to work in IPv6 at their LAN interface EVEN IF their WAN interface isn't operational.
This is intended to answer concerns that SHOULD might be insufficient.

> I think there's some confusion here.    The MUST is that CE is able to *generate* a randomised ULA prefix as per RFC4193.    ULA-1 isn't about what is advertised.   Indeed the default for whether U…

Right, good point.

The proposal should better have been:
"ULAL-1:   The IPv6 CE router SHOULD be capable of generating a pseudo-random ULA prefix [RFC4193]. If it isn't, it still MUST have an IPv6 prefix to use when its WAN interface is not operational, e.g. a ULA-like constant values like fd01::/48."

Note that, since user configuration of ULA prefixes is permitted, defaulting to fd00::/48 is equivalent, in unmanaged CPEs, to having a magic hand configuring it (fd00::/48 is a permitted possible of a pseudo-random generation).

That said, I don't "insist" on adding anything to draft-09 if it proceeds as is (i.e. with a SHOULD).
This is just an idea I submit.

Regards,
RD

---

From: Tim Chown <[email-masked]>
Date: Tue, 21 Dec 2010 12:40:04 +0000

> Note that, since user configuration of ULA prefixes is permitted, defaulting to fd00::/48 is equivalent, in unmanaged CPEs, to having a magic hand configuring it (fd00::/48 is a permitted possible…

Well, as it was in the -08 version, ULA-1 and ULA-2 taken together allow a CE to have its ULA prefix either automatically or manually configured, though the latter is a SHOULD.    So you don't need your extra text encouraging use of fd01::/48.   Yes, some users may do that, but I don't think we should suggest it.   

The ULA concept isn't really stated anywhere in the text.   Perhaps section 3.2.1 should say something like "Internal IPv6 LAN interfaces may be provisioned concurrently with both a delegated globally unique prefix and a ULA prefix.   The global prefix may then be used for communications to external hosts, while ULAs may be used on the internal network to give persistent addressing through external renumbering events (even for single LAN sites) or in the event of no external connectivity being available".   This may help avoid readers of the draft associating ULAs with NAT66.  

In practice the usefulness of ULAs - at least with current IPv4-style models and without considering SmartGrid type scenarios - will depend on whether IPv6 ISPs give customers dynamic IPv6 prefixes.   While you can argue ULAs may help in the event of a temporary connectivity outage, the existing global prefix should still be sufficient to maintain internal connectivity.    I think these issues are more likely to be incorporated in more detail in the -bis Advanced draft, but we shouldn't preclude the option to provision ULAs in the 'basic' CE definition.

Tim

---

From: Rémi Després <[email-masked]>
Date: Tue, 21 Dec 2010 15:57:17 +0100

Le 21 déc. 2010 à 13:40, Tim Chown a écrit :

> Well, as it was in the -08 version, ULA-1 and ULA-2 taken together allow a CE to have its ULA prefix either automatically or manually configured, though the latter is a SHOULD.    So you don't need your extra text encouraging use of fd01::/48.

>   Yes, some users may do that, but I don't think we should suggest it.

In my reading of -08, the ability to  it may either be pseudo-randomly or manually generated.
- This doesn't include a CPE that uses a predefined local prefix without manual configuration.
- This doesn't include either an ISP provided CPE that keeps using its last global IPv6 prefix when the WAN interface is down. (This is AFAIK what IPv6 users of Free have had since 2007, to their entire satisfaction).  

Do we want to formally exclude IPv6 operational behaviors that have proved to work?

> The ULA concept isn't really stated anywhere in the text.

IMHO, the reference to RFC4193 is enough (no need to revise -09 for this).

>   Perhaps section 3.2.1 should say something like "Internal IPv6 LAN interfaces may be provisioned concurrently with both a delegated globally unique prefix and a ULA prefix.   The global prefix may then be used for communications to external hosts, while ULAs may be used on the internal network to give persistent addressing through external renumbering events (even for single LAN sites) or in the event of no external connectivity being available".   This may help avoid readers of the draft associating ULAs with NAT66.

This part of the discussion has been closed.
AFAIK, the relationship with NAT66 is no longer asked to influence the document. 

> In practice the usefulness of ULAs - at least with current IPv4-style models and without considering SmartGrid type scenarios - will depend on whether IPv6 ISPs give customers dynamic IPv6 prefixes. While you can argue ULAs may help in the event of a temporary connectivity outage, the existing global prefix should still be sufficient to maintain internal connectivity.

Indeed.

>    I think these issues are more likely to be incorporated in more detail in the -bis Advanced draft, but we shouldn't preclude the option to provision ULAs in the 'basic' CE definition.

With a SHOULD, it isn't precluded, and some CPEs that do work don't see their behavior precluded.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Tue, 21 Dec 2010 16:34:29 +0100

Hi, James,

Le 20 déc. 2010 à 21:35, james woodyatt a écrit :
> ... if for the sake of ideological purity

If this ideological purity ends up precluding behaviors that have nicely word for years, shouldn't it be considered harmful?

> we need to change this from SHOULD back to MUST, then I won't object so long as the informative text is changed to explain why even the IPv6 CE routers that have only one LAN interface, or that do not permit forwarding between multiple LAN interfaces, MUST also support ULA addressing.

Actually, even if there are several LAN interfaces, a default /48 (i.e. one needing no manual configuration) is sufficient:
- A LAN-interface index can be added next the /48 to assign an exclusive prefix to each link. 

In an ISP-provided CPE with several LAN interfaces, the management of a pseudo-randomly generated ULA remains therefore a non mandatory function.

> I do not have any text to propose that would go to explaining that. Indeed, I cannot see any explanation that would make sense to my product managers.

Neither do I see how one could justify a MUST where a SHOULD is already so much in favor of what some CPE-providiong ISPs don't need.

Regards,
RD

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 21 Dec 2010 08:00:27 -0800 (PST)

Fred, I think this subject has been discussed and even over-discussed and a good 
compromise has been reached as in -09. I suggest declaring a closure on this. We 
have already shooted the horse to death.

My 0.2 cents.

Behcet

----- Original Message ----
> From: Fred Baker <[email-masked]>
> To: james woodyatt <[email-masked]>
> Cc: IPv6 Operations <[email-masked]>
> Sent: Mon, December 20, 2010 4:33:30 PM
> Subject: Re: [v6ops] Objection: draft-ietf-v6ops-ipv6-cpe-router-09.txt
> 
> > One of the things about IPv6  link-local addresses that makes them better 
>suited for use with mDNS than global  scope addresses is that the reverse DNS 
>mapping domains are naturally handled by  mDNS, whereas the reverse DNS mapping 
>domains for the ULA prefix this draft  requires will not be populated by any 
>content servers outside the local  network.  Pity this draft doesn't recommend 
>bundling a DNS content server  into IPv6 CE routers...
> > 
> > 
> > --

---

From: Fred Baker <[email-masked]>
Date: Tue, 21 Dec 2010 08:14:38 -0800

> have already shooted the horse to death.

I thought I did. In case there is any confusion on the point, I thought that the working group had closed the debate a number of months ago. Like all compromises, somebody isn't happy.

---

From: james woodyatt <[email-masked]>
Date: Tue, 21 Dec 2010 11:07:55 -0800

> If this ideological purity ends up precluding behaviors that have nicely word for years, shouldn't it be considered harmful?

I don't believe that to be a concern in this particular case.  I do know of certain, relatively common, dual-stack host implementations that will fail to interoperate properly in the presence of routers that conform to the -09 revision of this draft, but that's because of errors in their system software and not any problem with IETF documents.  It's within reason for the working group to conclude that exposure of some broken host implementations as what they are: broken-- is an acceptable cost of publishing these recommendations.

> [...]

For tactical reasons, I should probably come out in favor of MUST instead of SHOULD here, because then it certainly will be easier for me to argue to my product managers that conformance with this document is not recommended.  We decide to ignore SDO documents all the time when it suits us, and it will save my team some work in the future if we aren't burdened with some of the other things this document recommends, e.g. the L-7 and L-8 requirements.

I do not object to placing the current -09 revision on the "fast track" to the editor queue.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Dec 2010 11:53:26 +1300

Fred,

I'm sorry to prolong the thread, but:

> I thought I did. In case there is any confusion on the point, I thought that the working group had closed the debate a number of months ago. Like all compromises, somebody isn't happy. 

I agree. The 07 draft said

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

At a very late stage, there was a proposal to refine that to deal
with the worst aspects of the co-existence problem. That's fine,
but it is not fine to change the MUST to a SHOULD without a clear
consensus to do so (and, if we are strict, another IETF Last Call
and review by the IESG).

   Brian

---

From: <[email-masked]>
Date: Wed, 22 Dec 2010 09:16:05 +0100

>> "ULAL-1:   The IPv6 CE router SHOULD be capable of 
>generating a ULA prefix [RFC4193]. If it doesn't, it MUST 
>advertise an IPv6 prefix on each of its LAN interfaces even 
>when its WAN interfaces is not operational.  These prefixes 
>MAY be either those last used before the WAN interface 
>failure, or some ULA-like constant values (e.g. fd01::/48, 
>fd02::/48...)."
>
>I think there's some confusion here.    The MUST is that CE is 
>able to *generate* a randomised ULA prefix as per RFC4193.    
>ULA-1 isn't about what is advertised.   Indeed the default for 
>whether ULAs are advertised or not is not prescribed in the text. 

That's also how I read this and it's also my preferred wording in this context.

>
>The alternative if the CE is not able to generate such a 
>prefix is that the administrator/user generates their own ULA 
>prefix.    And then we know most will just use fd00::/48 or 
>something like fd12:3456:7890::/48, which isn't compliant with 
>ULAs as defined in RFC4193 section 3.2.   

+1 

cheers,
Chrisian
>
>The trick is to avoid exposing IPv6 literals to 
>administrators/users as far as possible so they don't feel the 
>need to use fd00::/48 just because it's easy.   But that's 
>something for the Advanced -bis draft I guess.
>
>Tim

---

From: Ole Troan <[email-masked]>
Date: Wed, 22 Dec 2010 09:58:17 +0100

Brian,

> consensus to do so (and, if we are strict, another IETF Last Call

L-1 was interpreted to mean two things. "support" as in capable of (author's intention) or "support" as in on by default.

what is implied by "ULA capability"?

- ability to configure and use addresses from the ULA prefix on interfaces
  - I can't imagine any CPE that allows you to do manually configured addresses
    could not support that. but I am not known for my imagination...
- automatically generate a ULA prefix
- be a site boundary router. presumably anything that supports ACLs will also support this

given that we also added the following paragraph in 08:
   "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."

I think SHOULD is fine, and a MUST would be in more conflict with the above paragraph.

from a pragmatic view point I don't think there is much difference.

what I wish for Christmas is an RFC... ;-)

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Wed, 22 Dec 2010 10:00:14 +0100

> what I wish for Christmas is an RFC... ;-)

All I want for Christmas
is my two RFCs,
my two RFCs,
see my two RFCs!

Ole