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

From: Ole Troan <[email-masked]>
Date: Fri, 3 Dec 2010 22:20:41 +0100

hi,

over the last week or so there has been background discussions on the recommendations for ULAs in the CPE router draft. (https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-cpe-router/)

it appeared that the text was not clear enough with regards to what "MUST  support ULAs" means. in addition it has come to light that a number of existing host implementations have problems with having only ULAs without global IPV6 addresses (in addition to an IPv4 address).

I've attached the diffset and the complete draft that includes these clarifications.
I do believe these are clarifications and I hope the working group and responsible AD would allow these changes during AUTH48.

cheers,
Ole

diff --git a/draft-ietf-v6ops-ipv6-cpe-router.xml b/draft-ietf-v6ops-ipv6-cpe-router.xml
index 85006e1..72bb1d6 100644
--- a/draft-ietf-v6ops-ipv6-cpe-router.xml
+++ b/draft-ietf-v6ops-ipv6-cpe-router.xml
@@ -31,8 +31,8 @@
          "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5072.xml">
 <!ENTITY I-D.ietf-v6ops-cpe-simple-security SYSTEM
      "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-v6ops-cpe-simple-security.xml">
-<!ENTITY I-D.ietf-6man-ipv6-subnet-model SYSTEM
-     "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6man-ipv6-subnet-model.xml">
+<!ENTITY RFC5942 SYSTEM
+     "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5942.xml">
 <!ENTITY RFC3736 SYSTEM
          "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3736.xml">
 <!ENTITY RFC4779 SYSTEM
@@ -47,10 +47,14 @@
          "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4443.xml">
 <!ENTITY RFC1122 SYSTEM
          "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1122.xml">
+<!ENTITY RFC3484 SYSTEM
+         "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3484.xml">
 <!ENTITY I-D.ietf-behave-v6v4-framework SYSTEM
      "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-behave-v6v4-framework.xml">
-<!ENTITY I-D.ietf-6man-node-req-bis SYSTEM
-     "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6man-node-req-bis.xml">
+<!ENTITY RFC4294 SYSTEM
+     "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4294.xml">
+<!ENTITY RFC4191 SYSTEM
+         "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4191.xml">
 ]>
 <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
 <!-- used by XSLT processors -->
@@ -77,7 +81,7 @@
 <?rfc subcompact="no" ?>
 <!-- keep one blank line between list items -->
 <!-- end of list of popular I-D processing instructions -->
-<rfc category="info" docName="draft-ietf-v6ops-ipv6-cpe-router-07" ipr="trust200902">
+<rfc category="info" docName="draft-ietf-v6ops-ipv6-cpe-router-08" ipr="trust200902">
   <!-- category values: std, bcp, info, exp, and historic ipr values:
      full3667, noModification3667, noDerivatives3667 you can add the
      attributes updates="NNNN" and obsoletes="NNNN" they will automatically be
@@ -165,7 +169,7 @@
       </address>
     </author>
 
-    <date month="August" year="2010" />
+    <date month="December" year="2010" />
 
     <!-- If the month and year are both specified and are the current ones,
          xml2rfc will fill in the current day for you. If only the current
@@ -354,13 +358,23 @@
       </list></t>
 
       <t>Unique Local IPv6 Unicast Addresses (ULA) <xref
-      target="RFC4193"></xref> are used by hosts communicating within
+      target="RFC4193"></xref> may be used by hosts communicating within
       the End-user Network; this is functionally similar to RFC1918
       addresses used within an IPv4 End-user Network. The IPv6 CE
       router defaults to acting as the demarcation point between two
       networks by providing a ULA boundary, a multicast zone boundary
       and ingress and egress traffic filters.</t>
 
+      <t>If ULA addresses are used in a network that is also connected
+      to the Internet, hosts may configure and use addresses from both
+      a ULA prefix and a global prefix. At the time of writing,
+      several host implementations have problems doing correct source
+      address selection <xref target="RFC3484"></xref> and failure
+      recovery when an interface has both a ULA address (that by
+      nature is topologically restricted) and a global address, be it
+      IPv4 or IPv6. It is for this reason recommended that ULA
+      addresses are used with caution.</t>
+
       <t>For IPv6 multicast traffic the IPv6 CE router may act as an
       Multicast Listener Discovery (MLD) proxy <xref
       target="RFC4605"></xref> and may support a dynamic multicast
@@ -389,8 +403,8 @@
 
         <t><list style='format G-%d:'>
 	  <t>An IPv6 CE router is an IPv6 node according to the <xref
-	  target="I-D.ietf-6man-node-req-bis"> IPv6 Node
-	  Requirements</xref> specification.</t>
+	  target="RFC4294"> IPv6 Node Requirements</xref>
+	  specification.</t>
 
 	  <t>The IPv6 CE router MUST implement ICMP according to <xref
 	  target="RFC4443"></xref>. In particular point to point links
@@ -401,6 +415,21 @@
 	  between its LAN Interface(s) and its WAN Interface until the
 	  router has successfully completed the IPv6 address
 	  acquisition process.</t>
+
+	  <t>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 <xref target="RFC4861"></xref>.</t>
+
+	  <t>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 <xref
+	  target="RFC4861"></xref>.</t>
+
       </list></t>
 
       </section>
@@ -474,8 +503,9 @@
             <t>The IPv6 CE router MUST support SLAAC <xref
             target="RFC4862"></xref>.</t>
             <t>The IPv6 CE router MUST follow the recommendation in
-            <xref target="I-D.ietf-6man-ipv6-subnet-model"></xref> and
-            in particular the handling of the L-flag in the Router
+            <xref target="RFC5942"></xref>.
+
+            and in particular the handling of the L-flag in the Router
             Advertisement Prefix Information Option.</t>
 
 	    <t>The IPv6 CE router MUST support DHCPv6 <xref
@@ -579,8 +609,8 @@
         characteristics:</t>
 
         <t><list style="numbers">
-            <t>Link-local addresses are insufficient for allowing IPv6
-            applications to communicate with each other in the
+            <t>Link-local addresses may be insufficient for allowing
+            IPv6 applications to communicate with each other in the
             end-user network. The IPv6 CE router will need to enable
             this communication by providing globally-scoped unicast
             addresses or ULAs <xref target="RFC4193"></xref> whether
@@ -598,9 +628,11 @@
         <t>Unless otherwise specified, the following requirements
         apply to the IPv6 CE router's LAN interfaces only.</t>
 
-        <t>Requirements:<list style='format L-%d:'>
+        <t>ULA requirements:<list style='format ULA-%d:'>
           <t>The IPv6 CE router MUST support ULA addressing <xref
-          target="RFC4193"></xref>.</t>
+          target="RFC4193"></xref>. This document takes no position on
+          whether ULA addressing is enabled by default or mechanisms
+          by which users would configure it.</t>
 
           <t>The IPv6 CE router MUST have a ULA prefix that it
           maintains consistently across reboots.</t>
@@ -613,6 +645,17 @@
           target="RFC4193"></xref> and filter packets with Local IPv6
           source or destination addresses accordingly.</t>
 
+	  <t>An IPv6 CE router that is configured with a ULA prefix
+	  MUST advertise itself as a router for the ULA prefix using
+	  the "Route Information Option" specified in <xref
+	  target="RFC4191"></xref>. This advertisement is independent
+	  of the IPv6 CE router having an IPv6 default router or
+	  not.</t>
+
+	</list></t>
+
+        <t>LAN requirements:<list style='format L-%d:'>
+
           <t>The IPv6 CE router MUST support router behavior according
           to Neighbor Discovery for IPv6 <xref
           target="RFC4861"></xref>.</t>
@@ -660,12 +703,7 @@
 	  ingress/egress policy) for packets forwarded to it using an
 	  address from a prefix which has been deprecated.</t>
 
-	  <t>If the IPv6 CE router loses its default route it SHOULD
-	  stop advertising itself as a default router. I.e. by setting
-	  the "Router Lifetime" field to 0 in subsequent Router
-	  Advertisement messages.</t>
-
-          </list></t>
+	</list></t>
 
       </section>
 
@@ -685,7 +723,7 @@
             functionality sufficient for implementing the set of
             recommendations in <xref
             target="I-D.ietf-v6ops-cpe-simple-security"></xref>
-            section 4. Ths document takes no position on whether such
+            section 4. This document takes no position on whether such
             functionality is enabled by default or mechanisms by which
             users would configure it.</t>
 
@@ -701,15 +739,16 @@
       <t>Thanks to the following people (in alphabetical order) for their
       guidance and feedback:</t>
 
-      <t>Mikael Abrahamsson, Merete Asak, Scott Beuker, Mohamed
-      Boucadair, Rex Bullinger, Brian Carpenter, Remi Denis-Courmont,
-      Gert Doering, Alain Durand, Katsunori Fukuoka, Tony Hain, Thomas
-      Herbst, Kevin Johns, Stephen Kramer, Victor Kuarsingh,
-      Francois-Xavier Le Bail, David Miles, Shin Miyakawa,
+      <t>Mikael Abrahamsson, Tore Anderson, Merete Asak, Scott Beuker,
+      Mohamed Boucadair, Rex Bullinger, Brian Carpenter, Lorenzo
+      Colitti, Remi Denis-Courmont, Gert Doering, Alain Durand,
+      Katsunori Fukuoka, Tony Hain, Thomas Herbst, Kevin Johns, Erik
+      Kline, Stephen Kramer, Victor Kuarsingh, Francois-Xavier Le
+      Bail, David Miles, Arifumi Matsumoto, Shin Miyakawa,
       Jean-Francois Mule, Michael Newbery, Carlos Pignataro, John
       Pomeroy, Antonio Querubin, Teemu Savolainen, Matt Schmitt,
-      Hiroki Sato, Mark Townsley, Bernie Volz, James Woodyatt, Dan
-      Wing and Cor Zwart</t>
+      Hiroki Sato, David Thaler, Mark Townsley, Bernie Volz, James
+      Woodyatt, Dan Wing and Cor Zwart</t>
 
       <t>This draft is based in part on CableLabs' eRouter specification.  The
       authors wish to acknowledge the additional contributors from the eRouter
@@ -764,7 +803,7 @@
       &RFC3646;
       &RFC4075;
       &RFC4193;
-      &I-D.ietf-6man-node-req-bis;
+      &RFC4294;
       &RFC4605;
       &RFC2827;
       &RFC2464;
@@ -774,13 +813,15 @@
       &RFC4779;
       &RFC4864;
       &RFC4242;
-      &I-D.ietf-6man-ipv6-subnet-model;
+      &RFC5942;
       &RFC4632;
       &RFC4443;
       &RFC1122;
+      &RFC4191;
     </references>
 
     <references title="Informative References">
+      &RFC3484;
       &I-D.ietf-behave-v6v4-framework;
       <reference anchor="UPnP-IGD"
 		 target="http://www.upnp.org/standardizeddcps/igd.asp">

---

From: Mark Baugher <[email-masked]>
Date: Sat, 4 Dec 2010 19:53:51 -0800

Thanks Ole.  I have a few comments following a quick read of the draft.  My general comment is that at least one SDO is using ULAs in its IPv6 addressing architecture and others will as well.  If there are problems with ULAs that require 'special caution' (p. 6), then it would be good to spell out those problems and what should be done for the sake of caution.    

I think this document spells out what "site" means in relation to RFC 4193 (p. 6), "The IPv6 CE router defaults to acting as the demarcation point between two networks by providing a ULA boundary, a multicast zone boundary and ingress and egress traffic filters."  Is this default specified in the requirements, such as in ULA-4.  In regard to this, ULA-4 might be more explicit in defining what an RFC 4193 'site' is in the context of a CPE router and what the scopes might be.  Popular services like UPnP will want to operate across routed network in the home and that means that UPnP devices need to be reachable by site-scope multicast. In some cases, it might be preferable to maintain multiple sites within the CPEs internal network, such as a low-powered sensor network that does not receive UPnP SSDP site-scope multicast.

There is one nit that I have, on page 4: "A typical IPv4 end-user network consist of a "plug and play" router with NAT functionality and a single link behind it..."  Practically every retail home gateway product I know of will run with no configuration (plug and play) but none will be secure and it is ill-advised to run in that mode.  Fortunately, the vast majority of owners of retail gateways in the US and other countries configure their products through an installation program or other means.  So I'd drop the "plug and play" from the sentence on page 4.

Mark

On Dec 3, 2010, at 1:20 PM, Ole Troan wrote:

> <draft-ietf-v6ops-ipv6-cpe-router-08.txt><diffs.txt>_______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Randy Bush <[email-masked]>
Date: Sun, 05 Dec 2010 13:07:22 +0900

> Thanks Ole.  I have a few comments following a quick read of the
> draft.  My general comment is that at least one SDO is using ULAs in
> its IPv6 addressing architecture and others will as well.  If there
> are problems with ULAs that require 'special caution' (p. 6), then it
> would be good to spell out those problems and what should be done for
> the sake of caution.

don't use it.  the experience with rfc 1918 space should be a lesson.
it always leaks [0].  it always causes trouble.

randy

--

[0] - see slides >=26 in geoff's ripe preso http://ripe61.ripe.net/presentations/290-IPv6_%E2%80%93_A_Content_Providers_Experiment.pdf

---

From: Randy Bush <[email-masked]>
Date: Sun, 05 Dec 2010 13:52:31 +0900

> [0] - see slides >=26 in geoff's ripe preso http://ripe61.ripe.net/presentations/290-IPv6_%E2%80%93_A_Content_Providers_Experiment.pdf

drc corrected me

http://ripe61.ripe.net/presentations/287-2010-11-18-ipv6-background-radiation.pdf

---

From: Joel Jaeggli <[email-masked]>
Date: Sat, 04 Dec 2010 20:48:32 -0800

>> are problems with ULAs that require 'special caution' (p. 6), then it

Any assumption that the they will be unique will be undermined by the
some knuclehead who is either you, your customer, or your peer. if you
follow the instructions on the package with ula-l your likelyhood of a
collision with some other use pciked at random is rather low, but policy
applied in aggregate can have all sorts of unintended consequences.

> it always leaks [0].  it always causes trouble.

We know how to solve the problem that motivated attaching a bunch of
rfc1918 instances to the internet. Assign more that a single ip, allow
for subnetting through delegation, do so automatically, use link local
addresses for link local traffic. Do so consistently on retail isps and
cpe and people will get used to seeing public ip's again.

> _______________________________________________
> v6ops mailing list
> [email-masked]

---

From: Mark Baugher <[email-masked]>
Date: Sat, 4 Dec 2010 22:33:51 -0800

On Dec 4, 2010, at 8:07 PM, Randy Bush wrote:

> don't use it.  

The proposal to use it was presented and discussed by this WG last year in the context of a local protocol suite, UPnP.  No dire warnings were voiced back then.

> the experience with rfc 1918 space should be a lesson.
> it always leaks [0].  

It's curious that you make this assertion and cite a reference that is about using public IPv6 addresses in a private context.  Do you think he's talking about ULAs?

Mark

> it always causes trouble.
> 
> randy
> 
> --
>

---

From: Mark Smith <[email-masked]>
Date: Sun, 5 Dec 2010 17:08:33 +1030

On Fri, 3 Dec 2010 22:20:41 +0100

> I do believe these are clarifications and I hope the working group and responsible AD would allow these changes during AUTH48.

Part of my work involves working with residential CPE IPv6 vendors to
get their IPv6 implementations up to scratch. Once they reach basic
functionality i.e. /64 over PPP via RA, DHCPv6-PD for LAN segment
addressing, and stateless DHCPv6 for service parameter assignment
(i.e. plug-and-play IPv6 Internet access), I've been using this draft as
a guide line as to what sorts of "beyond basic" functionality I should
suggest they add. Once it is published, I've been planning on using it
as a documented minimums for the CPE functionality I expect vendors to
provide.

I think the new ULA text is more ambiguous than it was before. I now do
not know who should make the ULA enable/support decision. The vendors
are in a position to, because they define the CPE factory defaults. In
markets where CPE is commonly purchased by end-users, operators have no
involvement in the matter. End-users shouldn't have to, and as I
believe IPv6 should be able to operate in somebody's home without
requiring them to have an active Internet service, I think ULAs should
be enabled by default. (People receiving CPE a week or two before their
Internet service is commissioned is a common enough scenario, and I
think people wanting to get their internal networking going before
their Internet connection is active would also be common enough)

If the fundamental problem is with RFC3484, isn't the fundamental
solution to fix that? This seems to be a chicken-and-egg problem. As
CPE firmware updates are performed far less regularly than end-node
updates, I think it would be better to push the consequences of RFC3484
issues to the end-nodes, rather than having the CPE loose baseline
functionality.

I'd be curious know more details about the specific problems that hosts
have with ULAs only and under what scenarios they occurred.

Thanks,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Sun, 5 Dec 2010 17:50:25 +1030

On Sun, 5 Dec 2010 17:08:33 +1030

> > I do believe these are clarifications and I hope the working group and responsible AD would allow these changes during AUTH48.
<snip>

> have with ULAs only and under what scenarios they occurred.

I'd also be curious to know if the Happy Eyeballs draft was considered
and/or would have any influence on these ULA/IPv4 failures.

Thanks,
Mark.

---

From: Tore Anderson <[email-masked]>
Date: Sun, 05 Dec 2010 13:17:08 +0100

* Mark Smith

> and/or would have any influence on these ULA/IPv4 failures.

Hello Mark,

The problem is that we currently have an installed base of millions or
even billions of devices that do not implement Happy Eyeballs or RFC
3484bis (note that the current RFC 3484 doesn't mention ULAs).

When these devices are dual-stacked using an ULA address as its only
IPv6 address plus an IPv6 default route, they will be unable to access
dual-stacked destinations without first enduring a connect() timeout for
every AAAA record published for the destination host name.  In other
words, we'll have another «broken user».

If this happens to a large amount of end users, we've essentially killed
off all efforts to get the content side to transition to IPv6 within the
foreseeable future.  We realised this was about to happen when we saw
these ULA-using IPv6 CEs that break dual-stack start appearing in the
wild, and therefore felt it was extremely important that the draft was
clarified to make it crystal clear that if ULAs are used, and the router
has no global IPv6 connectivity, a default route MUST NOT be advertised.
 This makes the host attempt IPv4 right away instead, and there is no
degradation of the user experience.

Happy Eyeballs is a promising long-term solution, but it is unrealistic
to assume it can be universally deployed before the transition to IPv6
is well underway.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Sun, 5 Dec 2010 15:41:30 +0000 (UTC)

On Fri, 3 Dec 2010, Ole Troan wrote:

Hi,

For 4191 type A and B nodes the CE router would still have to advertise
itself as default router which is strictly prevented by the MUST NOT
from ... in some cases.

Assume a CE router with only IPv4 connectivity or IPv6 connectivity w/o
a default route on the WAN interface. Further assume the address on the
WAN interface being used as tunnel endpoint or inside some other type of
VPN (beyond the scope of this email or the draft but possibly provider
managed in that case), this would essentially require manual
configuration or kill inter-site connectivity with ULA only prefixes,
as e.g. per RFC4193 4.7, for type A and B and thus restrict CE routers
that would implement features beyond "basic requirements".

Given that the draft mentions "small offices" and that plenty "cheap"
CE routers with tunnelling functionality existed, pardon, exist, for the
legacy only world, I would expect them to show up and being used in
similar kind of scenarios for IPv6 as well, especially during the next
(transition) years.

I would thus suggest to be careful with MUST NOT in this case so that
features beyond basic requirements whould not be prevented as the currently
"default/most concerning" use case may not be the only use case for
the lifetime of these products.

Alternatively the same trick as with WPD-8 would work, starting the
sentence with "*By default* an IPv6 CE router that has no ...",
leaving the vendor or user an option to make things work for them in
the above scenario but clearly preventing the currently pressing
problem by default.

/bz

-- 
Bjoern A. Zeeb                              Welcome a new stage of life.
         <ks> Going to jail sucks -- <bz> All my daemons like it!
   http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 5 Dec 2010 12:51:37 -0600

Bjoern,

This IPv6 CE router basic document does not support transition
mechanisms.  Thus there is no need to discuss any tunneled tech related
to transition mechanisms such a 6to4, DS-lite, 6RD etc.  As for your
other comments related to Type A and B kind of hosts, the IPv6 CE Router
document assumes the host will honor the MSR of RFC 4191.  Since the
IPv6 CE router document does not specify host behavior for a host such a
computer running Microsoft Windows or MAC OS, does it make sense to take
up host related specifications in the IETF BEHAVE WG?

Thanks,

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 5 Dec 2010 14:43:58 -0600

Mark,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Mark Smith
Sent: Sunday, December 05, 2010 2:20 AM
To: Mark Smith
Cc: IPv6 Operations; [email-masked]
Subject: Re: [v6ops] ULA & Basic Requirements for IPv6 Customer Edge
Routers

>and/or would have any influence on these ULA/IPv4 failures.

The Happy Eyeballs draft was quoted by us authors of the IPv6 CE router
document right away for the issue.  But operators told us it will be
some time before host will implement the Happy eyeballs draft.  I am not
worried about the other case of what if a host never upgrade its OS and
hence the host will not get the Happy Eyeballs implementation.  Such
ancient hosts should not expect latest and greatest IPv6 services. 

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 5 Dec 2010 14:48:41 -0600

Mark,

-----Original Message-----
From: Mark Smith
[mailto:[email-masked]] 
Sent: Sunday, December 05, 2010 1:39 AM
To: Ole Troan
Cc: IPv6 Operations; [email-masked]
Subject: Re: [v6ops] ULA & Basic Requirements for IPv6 Customer Edge
Routers

>I think ULAs should be enabled by default. (People receiving CPE a week
or two before their
>their Internet connection is active would also be common enough)

You are one operator who thinks ULA should be enabled by default.
However, the operators on the [email-masked] mailer such
as AT&T and Time Warner Cable and a person from CableLabs have voted
vehemently to ULA be disabled for the interim till some IPv6
specifications and IPv6 host and home router implementations mature.  I
personally voted the ULA to be enabled by default.  But I deferred to
the operators because they should have the final say.

Hemant

---

From: Randy Bush <[email-masked]>
Date: Mon, 06 Dec 2010 08:20:45 +0900

> However, the operators on the [email-masked] mailer

they need to speak up here.  having vendors say that operators have told
them X went out of fashion some time ago, even before the vendors said
there was no demand for ipv6.

randy

---

From: james woodyatt <[email-masked]>
Date: Sun, 05 Dec 2010 16:06:13 -0800

> there was no demand for ipv6.

Absolutely correct.  My own conversations with operations people have led me to think that not advertising a ULA prefix on the LAN bridge is perfectly acceptable behavior for an IPv6 residential gateway device.  I'm not feeling any pressure whatsoever to recommend that my employers revisit the decision to use IPv6-LL only on the home LAN bridge.

If there are operators and content providers insisting that IPv6 CPE routers must advertise ULA prefixes on LAN interfaces, then they haven't tried to make their case to me.  Let them speak up here in defense of these recommendations in I-D.ietf-v6ops-ipv6-cpe-router.  Personally, I think the current text about ULA in that draft should be removed entirely.

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

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 5 Dec 2010 18:24:17 -0600

James,

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

>Absolutely correct.  My own conversations with operations people have
led me to think that not advertising a ULA prefix on the LAN bridge is
perfectly acceptable behavior for an IPv6 residential gateway >device.
I'm not feeling any pressure whatsoever to recommend that my employers
revisit the decision to use IPv6-LL only on the home LAN bridge.

>If there are operators and content providers insisting that IPv6 CPE
routers must advertise ULA prefixes on LAN interfaces, then they haven't
tried to make their case to me.  Let them speak up here in >defense of
these recommendations in I-D.ietf-v6ops-ipv6-cpe-router.  Personally, I
think the current text about ULA in that draft should be removed
entirely.

This diffs of the new text that Ole sent out are correct for the ULA in
that the document remains silent on the ULA be enable by default or not.
Also, as I clearly said, the issue raised that caused the new text in
the draft is an issue not just restricted to the ULA but also for the
GUA.  James, you were already privy to the issue discussion and we
clearly said, without the ULA, (a) one cannot configure the IPv6 CE
router using the IPv6 link-local address, (b) the home IPv6 network
wants to function when the WAN and link is down, (c) the home network
prefix remains independent of the ISP renumbering of the GUA on the WAN,
and (d) the Smart gird folks have already decided that their smart meter
and home router will use ULA.

Thus, I think the ship has sailed to remove ULA prefix auto-generation
on the IPv6 CE router.  A vendor can be told by the ISP to disable the
ULA by default or not.

Hemant

---

From: Nathan Ward <[email-masked]>
Date: Mon, 6 Dec 2010 13:31:28 +1300

> on the IPv6 CE router.  A vendor can be told by the ISP to disable the

Assuming the ISP has a relationship with the vendor.

Here in NZ (and I understand Australia) it is rare for a CPE to be tied to an ISP. Industry standard defaults are a desirable thing.

--
Nathan Ward

---

From: George Michaelson <[email-masked]>
Date: Mon, 6 Dec 2010 10:35:52 +1000

> Here in NZ (and I understand Australia) it is rare for a CPE to be tied to an ISP. Industry standard defaults are a desirable thing.

Is there a table of which economies do routine CPE provisioning, and which expect the consumer to do their own?

I suspect NZ/AU may be the stand-outs.

We're both at high penetration rates for ADSL, and so are a) mature markets where the box sell rate is replace, not deploy and b) small markets. the total sell volume would be under 20million units combined.

My experience of asking people in europe is that they expect to be given a semi-sealed unit which is barely configurable by them. I've played with a Wanadoo unit in the UK, and was pretty closed: press one button for 30sec across power cycle to enable WPS detection of WiFi devices in the local net, then use a web UI to permit them in, and a limited RFC1918 config and ACL control. Very little sign of a customer-CPE config.

-G

---

From: Mark Baugher <[email-masked]>
Date: Sun, 5 Dec 2010 16:37:11 -0800

On Dec 5, 2010, at 4:06 PM, james woodyatt wrote:

> If there are operators and content providers insisting that IPv6 CPE routers must advertise ULA prefixes on LAN interfaces, then they haven't tried to make their case to me.  

What should operators and content providers have to say about a network that is owned and operated by the person who bought it?  ULA's are operator-independent addresses, and I don't see why operators or content providers (movie studios?) would set policy for someone's home network.    

> Let them speak up here in defense of these recommendations in I-D.ietf-v6ops-ipv6-cpe-router.

Why it's so important that they speak up?  It would be interesting to know if some uses or non-use of ULAs matters to them, but I doubt that it does.  ULAs support routed home networks for traffic that has no reason to go to the service provider or public Internet. It accommodates a world where not every home network consists solely of bridged LANs. 

Mark

>  Personally, I think the current text about ULA in that draft should be removed entirely.
> 
> 
> --

---

From: Randy Bush <[email-masked]>
Date: Mon, 06 Dec 2010 09:43:33 +0900

> Industry standard defaults are a desirable thing.

what a neat idea.  we should for an organization to standardize such
things
</sarcasm>

hemant, "the ship has sailed" is a good line but it just does not float.

randy

---

From: Randy Bush <[email-masked]>
Date: Mon, 06 Dec 2010 09:47:07 +0900

> What should operators and content providers have to say about

i'll remember that before placing our next large order

> Why it's so important that they speak up?

hemat, your fellow vendor, was invoking the old "operators have said
that" gambit.  i responded that, if those operators wanted to be heard,
they could speak up here, and his proxying them was just not acceptable.

randy, an operator who thinks ula sucks caterpillar snot

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 5 Dec 2010 19:19:29 -0600

Randy,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Randy Bush
Sent: Sunday, December 05, 2010 7:47 PM
To: Mark Baugher (mbaugher)
Cc: IPv6 Operations
Subject: Re: [v6ops] ULA & Basic Requirements for IPv6 Customer Edge
Routers

>randy, an operator who thinks ula sucks caterpillar snot

I have agreement from operators on the IPv6 CE router mailer that they
are OK with having the ULA disabled by default, so I don't understand
what the fuss is all about.  However a ULA disabled by default does not
mean the IPv6 CE router does not support the ability to generate a ULA
prefix if needed to; such as when the ULA is enabled.  This is the
bottom-line I envision.  Also, the same operators who want the ULA
disabled by default tell me it's only for a short time till hosts and
home routers fix their bugs - how short is short is up to them to reply
on and also what language does one use in the IPv6 CE router document to
signify the fact of keeping ULA disabled for a short time.

I ALSO ENCOURAGE you to read my other email where I said the problem
raised that caused new text for the IPv6 CE router is a problem that
also exists with the GUA.  So harking at the ULA is not fair and
correct.  I concur with Mark B.'s latest email.  I already gave fours
reasons for use of ULA in a email during the past few hours.

The train has left the station for the ULA (if the ship ran aground). Or
the cat is out of the bag for the ULA. 

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 5 Dec 2010 19:30:18 -0600

George, Randy. and Nathan,

This is what the latest text of the IPv6 CE router says towards enabling
of the ULA.

[This document takes no position on whether ULA addressing is enabled by
default or mechanisms by which users would configure it.]

I suggest we focus on at least this text and operators decided what if
anything needs to change for this text.  I also agree with Nathan that
he is correct that one assumed the ISP has a relationship with the
vendor which may not be a correct assumption.  Please wait for Monday
when the U.S. operators get to work and let them speak on the ULA and
thereafter if all operators can come to a consensus, we'd be happy to
reflect the consensus in the IPv6 CE Router document.  

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of George Michaelson
Sent: Sunday, December 05, 2010 7:36 PM
To: Nathan Ward
Cc: IPv6 Operations
Subject: Re: [v6ops] ULA & Basic Requirements for IPv6 Customer Edge
Routers

On 06/12/2010, at 10:31 AM, Nathan Ward wrote:

> Here in NZ (and I understand Australia) it is rare for a CPE to be
tied to an ISP. Industry standard defaults are a desirable thing.

Is there a table of which economies do routine CPE provisioning, and
which expect the consumer to do their own?

We're both at high penetration rates for ADSL, and so are a) mature
markets where the box sell rate is replace, not deploy and b) small
markets. the total sell volume would be under 20million units combined.

My experience of asking people in europe is that they expect to be given
a semi-sealed unit which is barely configurable by them. I've played
with a Wanadoo unit in the UK, and was pretty closed: press one button
for 30sec across power cycle to enable WPS detection of WiFi devices in
the local net, then use a web UI to permit them in, and a limited
RFC1918 config and ACL control. Very little sign of a customer-CPE
config.

-G

---

From: Randy Bush <[email-masked]>
Date: Mon, 06 Dec 2010 10:47:39 +0900

> I have agreement from operators on the IPv6 CE router mailer 

i have agreement on the psg vendor mailer that all vendors think the
opposite.

i will try one more time

SPEAKING FOR OTHERS IS NOT ACCEPTABLE

randy

---

From: Mark Baugher <[email-masked]>
Date: Sun, 5 Dec 2010 18:23:24 -0800

> i'll remember that before placing our next large order

I just don't know why you would care about ULAs in your next large order.

> randy, an operator who thinks ula sucks caterpillar snot

Well, then don't use them on your home network.  Or if you're providing home
gateways to subscribers, ensure that the feature is disabled.  If other
people choose to use ULAs and some of the bad things happen that have
been described on this thread, then that's not the operator's problem,
is it?

Mark

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 5 Dec 2010 20:44:10 -0600

Randy,

-----Original Message-----
From: Randy Bush [mailto:[email-masked]] 
Sent: Sunday, December 05, 2010 8:48 PM
To: Hemant Singh (shemant)
Cc: Mark Baugher (mbaugher); IPv6 Operations;
[email-masked]
Subject: Re: [v6ops] ULA & Basic Requirements for IPv6 Customer Edge
Routers

>SPEAKING FOR OTHERS IS NOT ACCEPTABLE

I work with a design team of us authors on the document and also several
operators from cable and DSL SP deployments from who we gained consensus
before Ole published the -08 version.  It would be good to verify some
facts before you jump the gun with statements in all-caps and the like.

Hemant

---

From: Roger Jørgensen <[email-masked]>
Date: Mon, 6 Dec 2010 03:49:15 +0100

I think this discussion kinda went wrong somewhere... but as far as I
know there are ONLY
individuals on this mailing list. That is that everyone represent them
self and not others. Or?

--- Roger J ---

-- 

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

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 5 Dec 2010 22:19:31 -0600

Randy,

Did you happen to note this text in my email below? Without the ULA, 

(a) One cannot configure the IPv6 CE router using the IPv6 link-local
address,
(b) The home IPv6 network wants to function when the WAN and link is
down,
(c) The home network prefix remains independent of the ISP renumbering
of the GUA on the WAN, and 
(d) the Smart gird folks have already decided that their smart meter and
home router will use ULA.

Thus, how specifically will you get around the issues raised without
using the ULA for IPv6?

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Hemant Singh (shemant)
Sent: Sunday, December 05, 2010 7:24 PM
To: james woodyatt; IPv6 Operations
Subject: Re: [v6ops] ULA & Basic Requirements for IPv6 Customer Edge
Routers

James,

-----Original Message-----

Hemant

---

From: Randy Bush <[email-masked]>
Date: Mon, 06 Dec 2010 14:09:25 +0900

> of the GUA on the WAN, and 

burn a bit of global address space into the devices.  there is enough to
number every grain of sand, or so we have been told for years

> home router will use ULA.

given the insanity of connecting one of the most fragile infrastructures
on the planet to the internet, i don't go to the smart grid for
archetectural advice.

randy

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 6 Dec 2010 07:24:18 +0100 (CET)

> RFC1918 config and ACL control. Very little sign of a customer-CPE 

Sweden is mixed.

"Everybody" uses ADSL PVC 8/35 and DHCP over RFC1483bridged so generally 
an ADSL CPE can be moved between ISPs if one only buys Internet service.

Some ship you a CPE which might be closed, semi-closed or open, some just 
ask you to go to your nearest electronics store to buy whatever you want, 
but giev you a list of CPEs they've tested as ok.

Personally I don't feel ULAs are an immediate issue, let's try to get dual 
stack working before we try to address IPv6 only.

Long term I do feel there is a need for the CPE to be reachable out of the 
box without Internet connection so I guess ULAs are needed for configuring 
it.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Fred Baker <[email-masked]>
Date: Sun, 5 Dec 2010 23:11:39 -0800

> on the planet to the internet, i don't go to the smart grid for

Being one who actually knows something about the Smart Grid...

(a) It is a trifle expansive to sat that "the smart grid folks have decided" any such thing. That is certainly what some vendors and the zigbee consortium are considering it. It is far from universal.

(b) There is a difference between using IP in a network and "connecting the network to the Internet". Yes, the Smart Grid is planning to use IP (and specifically IPv6) in parts of the grid. Nobody I am talking with plans to run it over the Internet except in a VPN, and that case only for non-mission-critical functionality.

---

From: Nathan Ward <[email-masked]>
Date: Mon, 6 Dec 2010 19:33:36 +1300

MDNS would work well for finding the router's admin screen - works for AEBS.

I see a need for ULA so that a home/small office can have stable addressing internally, even with multiple routers/ISPs.

You could do this by burning in global addresses as Randy suggests, but address selection (assuming you don't want to route those addresses globally) works better with ULA - now we just need the addrsel stuff more widely implemented/improved. Seems like leaving ULA off by default (but selectable) is a good recommendation for vendors until addrsel is better.

Apologies if this message is brief, it is sent from my cellphone.

On 6/12/2010, at 19:24, Mikael Abrahamsson <[email-masked]> wrote:

> "Everybody" uses ADSL PVC 8/35 and DHCP over RFC1483bridged so generally an ADSL CPE can be moved between ISPs if one only buys Internet service.
> 
> Some ship you a CPE which might be closed, semi-closed or open, some just ask you to go to your nearest electronics store to buy whatever you want, but giev you a list of CPEs they've tested as ok.
> 
> Personally I don't feel ULAs are an immediate issue, let's try to get dual stack working before we try to address IPv6 only.
> 
> Long term I do feel there is a need for the CPE to be reachable out of the box without Internet connection so I guess ULAs are needed for configuring it.
> 
> -- 
> !DSPAM:22,4cfc8198145871803816777!
> 
>

---

From: Mark Smith <[email-masked]>
Date: Mon, 6 Dec 2010 19:40:34 +1030

On Sun, 5 Dec 2010 16:37:11 -0800

> What should operators and content providers have to say about a network that is owned and operated by the person who bought it?  ULA's are operator-independent addresses, and I don't see why operat…

I agree with that. I've been looking at this draft both as an end-user
of IPv6 and as an operator. The draft is general enough to cover
functionality that is meeting both partys' needs. The ULA issue is one
where there appears to be an apparent conflict.

Tore's response to me identified that if the WAN interface isn't up
(and/or a global prefix isn't available), then the router lifetime
field is set to zero seconds in RAs, meaning that the CPE isn't
considered a default router, and therefore the end-node would only
consider the RA announced ULAs to be reachable. In effect, during that
time, ULAs would be come unique link local addresses, yet better than
link locals because the applications don't have to care about or be
aware of interfaces. I think this is a way of providing ULAs only for
disconnected networks, and a ULA + global addresses for IPv6 Internet
connected networks.

To provide inter-LAN interface routing on CPE, RFC4191 more specific
routes option could be used to overcome the CPE not announcing itself
as a default router when it doesn't have global Internet connectivity.

Regards,
Mark.

---

From: Nathan Ward <[email-masked]>
Date: Mon, 6 Dec 2010 22:16:40 +1300

(bungled sending this one the first time, apologies if you are one of the lucky few who gets it twice)

--
Nathan Ward

---

From: james woodyatt <[email-masked]>
Date: Mon, 06 Dec 2010 01:19:40 -0800

On Dec 5, 2010, at 20:19 , Hemant Singh (shemant) wrote:
> 
> (a) One cannot configure the IPv6 CE router using the IPv6 link-local address,

Not true.  mDNS-SD works fine using IPv6-LL addresses.  Apple has now shipped IPv6 CPE router products that are configured over IPv6 link-local with mDNS-SD for two generations.  If you don't like mDNS-SD, you could certainly adopt SLP instead.

> (b) The home IPv6 network wants to function when the WAN and link is down,

Apple supports isolated residential IPv6 networks with link-local today.

> (c) The home network prefix remains independent of the ISP renumbering of the GUA on the WAN,

IPv6 link-local is not global scope.

> (d) the Smart gird folks have already decided that their smart meter and home router will use ULA.

Their mistake, if they really did that.  I see no reason to help them cement themselves in.

---

From: Mark Smith <[email-masked]>
Date: Mon, 6 Dec 2010 20:02:50 +1030

On Mon, 06 Dec 2010 01:19:40 -0800

> Not true.  mDNS-SD works fine using IPv6-LL addresses.  Apple has now shipped IPv6 CPE router products that are configured over IPv6 link-local with mDNS-SD for two generations.  If you don't like…

Unfortunately I think the major drawback of LLs is that applications
have to be made interface aware. In other words, they have to get
involved in packet forwarding decisions - basically a layer violation.
ULAs, for on-link communications, absolve applications of that concern
because in effect they abstract the interface knowledge to within the
address itself, and let the underlying operating system use it's route
table take care of where packets are going to come from or go to.  

Regards,
Mark.

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Mon, 6 Dec 2010 10:29:38 +0000 (UTC)

On Sun, 5 Dec 2010, Hemant Singh (shemant) wrote:

Hi,

> mechanisms.
> Thus there is no need to discuss any tunneled tech related
> to transition mechanisms such a 6to4, DS-lite, 6RD etc.

I think there is some misunderstanding here. I wasn't talking about
those either.

RFC4193 4.7 is talking about "Use of Local IPv6 Addresses with VPNs".
The fact that I said tunneling is that I didn't want to list <n>
techniques that people use these days to accomplish that and that
current CE routers used by "small offices" here come with.

>  As for your

.. has to care about them if we are talking SLAAC and people are
concerned that functionality as stated in the draft would not prevent
use cases within or beyond the draft.

I realize that there's even the simpler case than a VPN that is
already described in the draft:

Ignoring 4191 Type A or B and the "MUST NOT advertise itself as an
IPv6 default router" might even mean that node on Network A in
Figure 1 of the draft could not reach any node on Network B in case of
ULA and no default router on the WAN interface.  It would require
manual configuration, which is exactly not what you want an end user
to do.
Do not asumme your printer knows what a "Route Information Option"
is just because it does (2462) SLAAC.

/bz

---

From: Ole Troan <[email-masked]>
Date: Mon, 6 Dec 2010 13:56:58 +0100

Bjoern,

[...]
> is just because it does (2462) SLAAC.

this is a balance between supporting global communication for existing hosts and allowing the possible use (future use) of ULAs.

please propose alternative text.

cheers,
Ole

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Mon, 6 Dec 2010 13:32:51 +0000 (UTC)

On Mon, 6 Dec 2010, Ole Troan wrote:

Hi,

> this is a balance between supporting global communication for existing hosts and allowing the possible use (future use) of ULAs.

It's not future.  It's used.

> please propose alternative text.

I did in my initial email during the weekend.

:: Alternatively the same trick as with WPD-8 would work, starting the
:: sentence with "*By default* an IPv6 CE router that has no ...",

/bz

---

From: Simon Perreault <[email-masked]>
Date: Mon, 06 Dec 2010 09:17:30 -0500

On 2010-12-06 04:32, Mark Smith wrote:
> the major drawback of LLs is that applications
> involved in packet forwarding decisions

This is false. Applications do not know what kind of address they are
using. They take a string and convert it to a sockaddr using the
OS-provided getaddrinfo() function. The interface ID is contained in the
sockaddr structure. That structure is opaque and applications should not
play with it. Then this structure is passed to the kernel as part of
socket system calls. The kernel is the one making the routing decisions.
There is no routing code necessary in applications to use LL addresses.

That was for C apps. Higher-level applications (e.g. Java) have even
less control on what happens, so LLs are definitely not a problem.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Don Sturek <[email-masked]>
Date: Mon, 6 Dec 2010 06:21:44 -0800 (PST)

On the point that "mDNS-SD works fine using IPv6-LL addresses", this is true, 
however, when using ROLL, IPv6-LL has as its scope just your immediate one-hop 
neighbor.

As one of the folks looking to use mDNS-SD in a smart energy deployment, we 
would like to extend this using ULAs to allow multicast resource discovery 
across an entire residence (including devices on WiFi, HomePlug and other 
networking technologies other than IEEE 802.15.4)

Don

________________________________
From: james woodyatt <[email-masked]>
To: IPv6 Operations <[email-masked]>
Sent: Mon, December 6, 2010 1:19:40 AM
Subject: Re: [v6ops] ULA & Basic Requirements for IPv6 Customer Edge Routers

> (a) One cannot configure the IPv6 CE router using the IPv6 link-local address,

Not true.  mDNS-SD works fine using IPv6-LL addresses.  Apple has now shipped 
IPv6 CPE router products that are configured over IPv6 link-local with mDNS-SD 
for two generations.  If you don't like mDNS-SD, you could certainly adopt SLP 
instead.

> (d) the Smart gird folks have already decided that their smart meter and home 

Their mistake, if they really did that.  I see no reason to help them cement 
themselves in.

---

From: Don Sturek <[email-masked]>
Date: Mon, 6 Dec 2010 06:26:30 -0800 (PST)

Hi Randy,

Could you let me know who besides the ZigBee Alliance have smart metering home 
area networking deployments and what technology they are using for resource 
discovery?

Thanks,

Don

________________________________
From: Fred Baker <[email-masked]>
To: Randy Bush <[email-masked]>; Hemant Singh (shemant) <[email-masked]>
Cc: IPv6 Operations <[email-masked]>
Sent: Sun, December 5, 2010 11:11:39 PM
Subject: Re: [v6ops] ULA & Basic Requirements for IPv6 Customer Edge Routers

(a) It is a trifle expansive to sat that "the smart grid folks have decided" any 
such thing. That is certainly what some vendors and the zigbee consortium are 
considering it. It is far from universal.

(b) There is a difference between using IP in a network and "connecting the 
network to the Internet". Yes, the Smart Grid is planning to use IP (and 
specifically IPv6) in parts of the grid. Nobody I am talking with plans to run 
it over the Internet except in a VPN, and that case only for 
non-mission-critical functionality.
_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 6 Dec 2010 08:30:52 -0600

Mark,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Smith
Sent: Monday, December 06, 2010 4:33 AM
To: james woodyatt
Cc: IPv6 Operations
Subject: Re: [v6ops] ULA & Basic Requirements for IPv6 Customer Edge Routers

> Not true.  mDNS-SD works fine using IPv6-LL addresses.  Apple has now shipped IPv6 CPE router products that are configured over IPv6 link-local with mDNS-SD for two generations.  If you don't like…

Just because one product happens to work does not mean there is a problem.  In 2008 v6ops closed the IPv6 link-local as inadequate for configuration via the web.  I found the closure in v6ops from a July 7, 2008 email from Rémi Denis-Courmont who said the following (shown between square brackets below):

[Most (at least quite many) IPv6 applications are incapable of using link-local addresses, owing to the peculiar way the socket API deals with them. Namely, it requires that the socket address scope ID be set. The only way to have fully operational LAN communications is to keep an ULA prefix always, regardless of cascading. And it should preferably remain present even if the WAN connection has succeeded, so that: - pre-existing connections don't break needlessly when the WAN goes up,

I tried two different browsers.

In both of them http://[fe80::211:11ff:fe12:3456]:8080/ resulted in a connection failure. I had to type http://[fe80::211:11ff:fe12:3456%eth0]:8080/ which violates the HTTP URI spec, and requires that I know how my network interface is called.]

Hemant

---

From: Nathan Ward <[email-masked]>
Date: Tue, 7 Dec 2010 03:36:05 +1300

> In both of them http://[fe80::211:11ff:fe12:3456]:8080/ resulted in a connection failure. I had to type http://[fe80::211:11ff:fe12:3456%eth0]:8080/ which violates the HTTP URI spec, and requires t…

Mark is talking about using mDNS-SD - typing names, not IPv6 addresses, in to address boxes.

--
Nathan Ward

---

From: Ole Troan <[email-masked]>
Date: Mon, 6 Dec 2010 16:13:07 +0100

Bjoern,

> :: sentence with "*By default* an IPv6 CE router that has no ...",

splendid. the intention was certainly not to have text prohibit manual configuration.

if the text read:

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

that would be acceptable?

cheers,
Ole

---

From: Mark Baugher <[email-masked]>
Date: Mon, 6 Dec 2010 07:20:42 -0800

> which expect the consumer to do their own?

I'd like to see such a table.  In the US, it's largely done by the customer.  I believe that the SP configures and manages the CPE in many European countries. 

Mark

---

From: james woodyatt <[email-masked]>
Date: Mon, 06 Dec 2010 08:03:07 -0800

On Dec 6, 2010, at 01:32, Mark Smith wrote:
> 
> Unfortunately I think the major drawback of LLs is that applications have to be made interface aware.

Only those applications that rest directly on the standard POSIX interfaces need to be aware of address scope identifiers in the address structure.  Applications that rest on sensible higher-level frameworks, those which are mature today and integrate nicely with service discovery protocols, can remain blissfully ignorant of network interface identifiers.

---

From: Ole Troan <[email-masked]>
Date: Mon, 6 Dec 2010 17:05:00 +0100

James,

> Only those applications that rest directly on the standard POSIX interfaces need to be aware of address scope identifiers in the address structure.  Applications that rest on sensible higher-level…

I think we have concluded that there will be multiple links in the home and that in general link-local addressing is not sufficient. of course, I don't see much of a problem using it to configure the CPE (which can be done with v4 as well). if one has a CPE that has to be configured...

cheers,
Ole

---

From: Fred Baker <[email-masked]>
Date: Mon, 6 Dec 2010 08:16:17 -0800

I took cpe-router off the CC line. Folks on the design team are on the general mailer, so I don't see value in cross-posting them, and doing so to public lists tends to make private lists spam paths. If folks want to be on the design team, which is to say that they plan to offer text, drop me a note privately and I'll add you.

> I'd like to see such a table.  In the US, it's largely done by the customer.  I believe that the SP configures and manages the CPE in many European countries. 

My understanding is that managed CPE service is not so much a national thing as it is a service thing. SPs often have, both at the residential and corporate level, services in which the customer provides his own CPE and services in which the SP manages the CPE for a fee. Managed CPE services tend to target the mid-range of the customer base - high-end residential (sometimes called SOHO, Prosumer, Business, or Commercial services) and smaller companies that outsource some or all of their IT services. If one is using that kind of a service, one is also paying for the service. General residential service usually includes installation of a Cable or DSL "modem" at the home, which may contain a low functionality CPE router, but any time spent actually managing it is on a trouble ticket basis because the revenue doesn't pay for it, and configurations are very standard on a per-operator basis.

As a result, I think trying to develop such a table is a rat-hole. I'm willing to be told I'm wrong.

What might be more helpful is for companies that offer managed CPE services to interact with the design team on their requirements. Cable Labs and BBF are involved already, which are operational consortia, but there are also operators on the design team.

As to the general support of ULAs... A ULA is an RFC 4291 unicast prefix. If the device can use an RFC 4291 prefix, it can use a ULA. So requiring the CPE Router to be configurable with a ULA is to me an empty statement - it should be configurable with any legal unicast prefix, end of discussion. The real question is the one that the document has explicitly backed away from making - will it do the RFC 4193 randomization algorithm to generate a ULA and use it "internally"?

I'll pass along the comment I made to the design team, in slightly less terse form.

Department store residential IPv4 routers (Linksys, D-Link, Netgear, etc) generally have an RFC 1918 prefix on the interior side and NAT upstream. There are two reasons: (1) due to the NAT function, it *has* to provide a prefix internally, and (2) to configure the router, the simplest approach is to access it as a web server at a well-known address. This address is often 10.0.0.1 or 192.168.0.1. 

Department store residential IPv6 routers can expect to get a prefix from their upstreams and implement it internally. So the first reason doesn't make much sense in an IPv6 network. However, router configuration before attaching to the upstream, or continued in-home operation during upstream outages, requires some form of independent prefix. In a network that has no internal routing (there may be switches or access points in the home but no routers apart from the CPE), IPv6 link-local addresses may be adequate. But they have issues; I note that some of the equipment in my home (my printer) that is IPv6-capable will not generate or use a link-local address in the absence of an IPv6 router. That may simply be a bug, but to me it's a concern. So for (2), link-local may or may not be adequate. In any event, it becomes a place for an mDNS or local DNS proxy implementation that will let people access https://myRouter.local or some such thing.

In an internal network with routing, link-local is clearly inadequate. Since it is possible for the residential network to be disconnected from its upstream, both during installation and during outages, usage of a ULA for router access, printer access, and local A/V services within the home makes a lot of sense to me.

To my mind, that argues for an ability within the residential router to perform the RFC 4193 prefix generation algorithm. It might be on command or by default. The argument for it being "by default" has to do with the rationality of using link-local addresses within a home that has no internal routing. Do we interpret RFCs 4291 and 2460 as requiring edge nodes to generate and use link-local addressing even in a network that has no other IPv6 traffic? If so (e.g. if the equipment I am observing has a bug), I don't see it as needing to be on by default; the administrator can trigger configuration if he wants it. If link-local cannot be depended on when the network consists entirely of the host and the router, then I think a ULA is required for configuration of the router, and must be generated before the router is configured.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 6 Dec 2010 10:40:07 -0600

James,

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

address,

>Not true.  mDNS-SD works fine using IPv6-LL addresses.  Apple has now
shipped IPv6 CPE router products that are configured over IPv6
link-local with mDNS-SD for two generations.  If you don't like
mDNS->SD, you could certainly adopt SLP instead.

What if all interfaces on the LAN of the IPv6 CE router have the same
IPv6 link-local address?  Then one ends up using extra labeling with the
IPV6 addresses to make mDNS work, right?  For example, all the LAN
interfaces use FE80::1 and each device connected to each LAN interface
has Fe80::2.  So how does the computer attached to, say,  interface 2,
print to the printer off of interface 3?  How does such a specific
example also work with a generic web browser?  There is a further bigger
problem.  The Basic IPv6 CE router document covers a single router in
the home.  However, we authors of the document do not add any text to
this Basic document if the text breaks the two-router case in the home.
mDNS will not work if one has two routers.  That is why Service
Discovery and mDNS got punted out of the Basic IPv6 CE router document
as future work.

down,

>Apple supports isolated residential IPv6 networks with link-local
today.

Which RFC defines data forwarding behavior of this "isolated residential
IPv6 networks with link-local" from Apple?  Also note, any LAN interface
of the IPv6 CE router may be a routed interface and then IPv6 link-local
based forwarding breaks down.  

>IPv6 link-local is not global scope.

See above.  IPv6 link-local does not suffice for the routed LAN.

>Their mistake, if they really did that.  I see no reason to help them
cement themselves in.

I am also replying to Fred Baker's email on this one.  I agree with Fred
that my response was a little too strong.  I thought since we authors of
the IPv6 CE router document were asked by Fred to cater to the Smart
Grid cpeenhancements document, the ULA was acceptable to the Smart Grid
community.  The reason is, the ULA is one requirement from the
cpeenhancements document.

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 6 Dec 2010 10:41:37 -0600

Randy,

-----Original Message-----
From: Randy Bush [mailto:[email-masked]] 
Sent: Monday, December 06, 2010 12:09 AM
To: Hemant Singh (shemant)
Cc: james woodyatt; IPv6 Operations
Subject: Re: [v6ops] ULA & Basic Requirements for IPv6 Customer Edge
Routers

>number every grain of sand, or so we have been told for years

Who decides the assignment of such global address space from one home
router to another?  

Hemant

---

From: Thomas Herbst <[email-masked]>
Date: Mon, 6 Dec 2010 09:26:16 -0800

When you have a routed premises, LL is no longer sufficient to enable local connectivity when there is not global connectivity.   Not being able to locally print on my printer (or access any other server) because the DSL is down would constitute a broken architecture.  

tom

---

From: Mark Baugher <[email-masked]>
Date: Mon, 6 Dec 2010 09:48:15 -0800

> As a result, I think trying to develop such a table is a rat-hole. I'm willing to be told I'm wrong.
Sorry, I don't propose that the WG needs to develop such a table.  I just made a personal statement that I'm interested in how these products are  used world-wide because my view tends to be US-centric.

Mark

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Mon, 6 Dec 2010 17:51:42 +0000 (UTC)

Bjoern,

>         field is set to zero in all Router Advertisement messages it

That's ok with me.

> that would be acceptable?

And that's the logical continuation.

Perfect, thanks:-)

Regards,
Bjoern

---

From: Mark Baugher <[email-masked]>
Date: Mon, 6 Dec 2010 10:22:32 -0800

I pretty much agree with what you say but have a couple of comments.

On Dec 6, 2010, at 8:16 AM, Fred Baker wrote:

> My understanding is that managed CPE service is not so much a national thing as it is a service thing.

Yes, I agree.  Some SPs have different policies internationally than they do locally for providing various CPEs and services, however, and often this is regional, e.g. a Spanish operator might offer different services in S.America than in Europe.

> SPs often have, both at the residential and corporate level, services in which the customer provides his own CPE and services in which the SP manages the CPE for a fee. Managed CPE services tend to target the mid-range of the customer base - high-end residential (sometimes called SOHO, Prosumer, Business, or Commercial services) and smaller companies that outsource some or all of their IT services. If one is using that kind of a service, one is also paying for the service. General residential service usually includes installation of a Cable or DSL "modem" at the home, which may contain a low functionality CPE router, but any time spent actually managing it is on a trouble ticket basis because the revenue doesn't pay for it, and configurations are very standard on a per-operator basis.
> 

I think #2 is more of an artifact than a reason:  It's actually cleaner to develop an app than to require a home user to type in an IP address into a browser and deal with the issues and insecurities of using a web browser.  That latter is more suitable for engineers than the typical CPE user.

> To my mind, that argues for an ability within the residential router to perform the RFC 4193 prefix generation algorithm. It might be on command or by default. The argument for it being "by default" has to do with the rationality of using link-local addresses within a home that has no internal routing. Do we interpret RFCs 4291 and 2460 as requiring edge nodes to generate and use link-local addressing even in a network that has no other IPv6 traffic?

I thought link-local was required and guaranteed to be available.  I cannot find that requirement although RFC 4862 requires it for autoconfiguration.

> If so (e.g. if the equipment I am observing has a bug), I don't see it as needing to be on by default; the administrator can trigger configuration if he wants it. If link-local cannot be depended on when the network consists entirely of the host and the router, then I think a ULA is required for configuration of the router, and must be generated before the router is configured.

I see.

From a host perspective, I assume that the most robust approach to local connectivity would be to always use link-local and site-local multicast and try to use all address options when interoperating in a small network like a home network, including global addresses, e.g. in the case where site-local multicast takes you off the link but there is no ULA available.

Mark

---

From: Randy Bush <[email-masked]>
Date: Mon, 06 Dec 2010 10:27:45 -0800

> Hi Randy,
> 
> Could you let me know who besides the ZigBee Alliance have smart
> metering home area networking deployments and what technology they are
> using for resource discovery?

nope.  i was not the one who said that, hemat was speaking for a third
party as usual.  his message style does not make clear what is quoted
and what is his text, so you were misled that i had written it.

randy

---

From: Randy Bush <[email-masked]>
Date: Mon, 06 Dec 2010 10:28:16 -0800

> burn a bit of global address space into the devices.  there is enough
> to number every grain of sand, or so we have been told for years

who decides what mac to burn into the device?

randy

---

From: Thomas Herbst <[email-masked]>
Date: Mon, 6 Dec 2010 10:29:59 -0800

Thanks for the equivalent to "I haven't read the draft, but..."

The part of the "Smart Grid" (a marketing term) that we are talking about is a coms module in a meter at a house communicating with the devices in the house.  As long as the board in the meter doesn't start on fire, the electrons will flow.

The need to use ULA's is from two places -- 1) 802.15.4 mac/phy has different a different packet format than 802.2/802.3, and 2) RPL/ROLL route over mesh broke LL such that you can't even use LL across the mesh.  

Burning in a magic chunk of GUA sounds very similar to using ULA's, with all the same issues. 

Tom
-----------------------------------------------------------------

randy

---

From: Don Sturek <[email-masked]>
Date: Mon, 6 Dec 2010 10:30:26 -0800 (PST)

Hi Randy,

Sorry to attribute that to you.

However, to those on the list, if you do know of other smart energy deployments 
and their resource/service discovery technology selection, let me know.  Just 
want to be sure we aren't taking on more than we need to.  We already looked at 
SLP, uPnP and rejected them due to various requirements....

Thanks,

Don

________________________________
From: Randy Bush <[email-masked]>
To: Don Sturek <[email-masked]>
Cc: Fred Baker <[email-masked]>; Hemant Singh (shemant) <[email-masked]>; 
IPv6 Operations <[email-masked]>
Sent: Mon, December 6, 2010 10:27:45 AM
Subject: Re: [v6ops] ULA & Basic Requirements for IPv6 Customer Edge Routers

randy

---

From: Thomas Herbst <[email-masked]>
Date: Mon, 6 Dec 2010 10:36:04 -0800

Almost every m-DNS document I've read has a comment about how a broader scope could be used, but is not defined.

Local multicast/LL vs site local multicast/ULA seems to be to make enterprise campus administration easier rather than anything to do with the residence or small business.  

"Works just fine" is true in the current all bridged 802.3 frame world. With requirements to route in the home such as the addition of 802.15.4 wireless LANs, it does not meet the needs as implemented.

If I'd selected the wireless interface in the electric meters, I likely would have gone with 802.11, but 802.15.4 was selected and is widely installed. 

tom

---

From: Fred Baker <[email-masked]>
Date: Mon, 6 Dec 2010 10:41:21 -0800

On Dec 6, 2010, at 10:22 AM, Mark Baugher wrote:

> site-local multicast

Someday when someone has some time, I would like an explanation of "site-local" that doesn't involve a network administration configuring some form of filter in the exact set of interfaces (not routers, interfaces) that constitute the edge of a site. 

In case you are wondering why the distinction between routers and interfaces there, consider this case:

                        |Link to upstream
                        |network or provider
                   +----+-----+
                   |          |
        -----------+  Router  +------------
       Link to     |          |      Link to
       somewhere   +----+-----+      somewhere
       else within      |            else outside
       sit         -----+------      site
                      Local LAN

A site-local multicast may be routed between the local LAN and "somewhere else within the site", but not "outside" or "upstream". Is a "site" "my company"? If so, Cisco's concept of a "site" might be somewhat breathtaking. Is it a campus? A building? A cube? What the !@#$%^ is a site?

As near as I can tell, the definition is in the hands of the local administration, and requires some form of "edge" - a filter in a routing protocol, an air gap in the routing protocol (between a CPE and its upstream perhaps), or something. And that filter/gap/whatever has to be in every place that should be considered an edge and nowhere else.

Considering the frequency of reports of 0.0.0.0/0, RFC 1918 prefixes, and other martians being advertised in routing, I tend to think that any such definition is full of holes.

---

From: Gert Doering <[email-masked]>
Date: Mon, 6 Dec 2010 19:53:13 +0100

Hi,

On Mon, Dec 06, 2010 at 10:40:07AM -0600, Hemant Singh (shemant) wrote:
> print to the printer off of interface 3?  

Not, obviously.  fe80 is for communication in a bridged environment and
will not pass routers.

It doesn't need to, to print in a typical *zero-conf* environment - if
you add extra networks, you need to have routable space.  Global or ULA.

Gert Doering
        -- NetMaster
-- 
did you enable IPv6 on something today...?

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

---

From: Gert Doering <[email-masked]>
Date: Mon, 6 Dec 2010 20:01:52 +0100

Hi Ole,

>          field is set to zero in all Router Advertisement messages it

I see a big problem here:

- what if the router is set up to bring up its WAN interface only 
  on-demand, because it's connected to something that is billed by 
  online-time (or whatever reason)?  For that function, the router 
  typically uses packets that need to be sent to the WAN to trigger 
  "bring up WAN link" - and it will never see these packets under
  the conditions of G-4.

> that would be acceptable?

Now that would be fine - if the link is down, give the hosts a chance to
either pick another router, or tell the applications that v6 is unavailable.

Combined with dial-on-demand things, this brings back the problem I have
with G-4, tho.

Gert Doering
        -- NetMaster

---

From: Mark Baugher <[email-masked]>
Date: Mon, 6 Dec 2010 11:09:39 -0800

> In case you are wondering why the distinction between routers and interfaces there, consider this case:

That was a complaint with site-local unicast IIRC.  ULA skipped the problem at the address level.  But we are still left with the problem of defining the site.  I was indirectly asking Ole, Hemant, et. al. to do that in the CPE router draft and assuming, rightly or wrongly, that the interface boundaries for a CPE router assigning ULA prefixes would be coincident with the boundaries for forwarding site-local multicast packets.  

> As near as I can tell, the definition is in the hands of the local administration, and requires some form of "edge" - a filter in a routing protocol, an air gap in the routing protocol (between a C…

It might be hard to define a site in general, but we may often know one when we see it.  At least in the case of today's retail gateway/router products, it seems clear because they have two sets of interfaces - one to the broadband provider and one or more to internal devices, which I assume would be the local site.  It gets more complicated when we introduce routing, low-powered sensor networks, etc.

Mark

---

From: Ole Troan <[email-masked]>
Date: Mon, 6 Dec 2010 20:41:08 +0100

Mark,

> That was a complaint with site-local unicast IIRC.  ULA skipped the problem at the address level.  But we are still left with the problem of defining the site.  I was indirectly asking Ole, Hemant,…

indeed. in the scope of this draft the ULA boundaries are well defined.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Mon, 6 Dec 2010 20:46:09 +0100

Gert,

> Combined with dial-on-demand things, this brings back the problem I have

this document has not consider dial-on-demand. I would be happy to consider it out of scope. in any case doesn't "by default" take care of it. in a dial-on-demand mode a CPE has to be configured to work differently. 

cheers,
Ole

---

From: Michael Newbery <[email-masked]>
Date: Tue, 7 Dec 2010 08:54:49 +1300

> number every grain of sand, or so we have been told for years

But doesn't that suffer from another problem: treating the IP address as an identifier rather than a locator?
Unless you choose an IPv6 prefix that is globally defined as having no geographical scope---which pretty much defines ULA.

I wonder if the real trap here is in trying to misuse an address as an ID. (In which case, using a ULA as an ID is ipso facto Bad.)

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 06 Dec 2010 22:51:47 +0100

On Mon, 06 Dec 2010 08:03:07 -0800, james woodyatt <[email-masked]> wrote:
> have to be made interface aware.
> 
> Only those applications that rest directly on the standard POSIX
> interfaces need to be aware of address scope identifiers in the address
> structure.  Applications that rest on sensible higher-level frameworks,
> those which are mature today and integrate nicely with service discovery
> protocols, can remain blissfully ignorant of network interface
identifiers.

Oh yeah? The most widely used rendez-vous mechanism on the Internet today
is the HTTP URI. This is also the most commonly used rendez-vous mechanism
to configure your average CPE router. And there is no _standard_ way to
stuff a scope identifier in an HTTP URI.

Some browsers might support http://[IPv6_ADDRESS]%SCOPE/ notation? or maybe
http://[IPv6_ADDRESS%SCOPE]/ instead? or maybe both? Some won't support
any. But this is irrelevant. A CPE vendor probably wants a single unique
HTTP URI that will always work and can be printed in the manual. This has
to work for all browsers, all platforms, and all combination of network
interfaces on the PC. So you cannot depend on scope identifiers here.

I can imagine the manual:
"If you are using Windows, please point your browser to http://myrouter%1 .
If that does not work, please try http://myrouter%2 .
If you are using Linux, please point your browser to http://myrouter%eth0
or http://myrouter%eth1 or http://myrouter%wlan0 (...)"

Now, you could argue that ULA do not fix that problem because they are
unique by definition. That would be a good point. That's why I'd expect the
vendors to hard-code some kind of name provisioned through DNS. But of
course, vendors will anyway recommend using IPv4 to configure the CPE for
quite many years to come.

-- 
Rémi Denis-Courmont
http://www.remlab.net
http://fi.linkedin.com/in/remidenis

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 6 Dec 2010 14:29:16 -0800 (PST)

> Their mistake, if they really did that.  I see no  reason to help them cement 

Well, in Zigbee network, link-local provides communication only for directly 
adjacent neighbors (due to their current use of so-called route-over or IP 
routing) and they wish to use ULA for mesh network-wide, e.g. home area network 
(HAN).

I think there is a draft being written to extend mDNS to support ULAs.

---

From: Michael Newbery <[email-masked]>
Date: Tue, 7 Dec 2010 11:30:05 +1300

> interfaces on the PC. So you cannot depend on scope identifiers here.

But if you want a unique URI printed in the manual, an IPv6 address isn't such a good idea. A link-local is dynamic, normally based on the MAC address, so you'll either need to print a custom manual for each CPE, or have the URI printed on the CPE along with the MAC address and serial number.

But, if you make the CPE speak mDNS, then you can print http://my-router.local and have reasonable confidence that it will work.

---

From: Bruce Zamaere <[email-masked]>
Date: Tue, 7 Dec 2010 01:14:09 +0100

I am aware that I am entering this discussion pretty late and run the risk
of flogging a dead horse. IMHO I still see a need for ULAs in CPEs
especially in residential networks. It would be interesting to see possible
solutions for the dial-on-demand problem that Gert brought up earlier though
I do admit its an exception and should probably be looked into later.

/Bruce.

On Mon, Dec 6, 2010 at 11:30 PM, Michael Newbery <[email-masked]> wrote:

> But if you want a unique URI printed in the manual, an IPv6 address isn't
> such a good idea. A link-local is dynamic, normally based on the MAC
> address, so you'll either need to print a custom manual for each CPE, or
> have the URI printed on the CPE along with the MAC address and serial
> number.
>
> But, if you make the CPE speak mDNS, then you can print
> http://my-router.local and have reasonable confidence that it will work.

---

From: james woodyatt <[email-masked]>
Date: Mon, 06 Dec 2010 16:32:47 -0800

> I do believe these are clarifications and I hope the working group and responsible AD would allow these changes during AUTH48.

Regarding...

   ULA-5:  An IPv6 CE router that is configured with a ULA prefix MUST
           advertise itself as a router for the ULA prefix using the
           "Route Information Option" specified in [RFC4191].  This
           advertisement is independent of the IPv6 CE router having an
           IPv6 default router or not.

The operator community and the CPE router equipment vendor community may be interested to know that no Apple products currently support the More-specific Route Option in RFC 4191, i.e. they all ignore any such options present in router advertisements.

The significance of this fact to the current discussion would be that telling Mac OS X and iOS users to type "http://[fd00:xxxx:xxxx:xxxx::1]" into a web browser input dialogue to open the configuration page of an unconfigured IPv6 CPE router, when the it isn't advertising a non-zero ValidLifetime, i.e. it has no upstream default router of its own, is unlikely to result in a winning user experience.

---

From: Ole Troan <[email-masked]>
Date: Tue, 7 Dec 2010 01:41:52 +0100

James,

> The significance of this fact to the current discussion would be that telling Mac OS X and iOS users to type "http://[fd00:xxxx:xxxx:xxxx::1]" into a web browser input dialogue to open the configur…

not sure I see the correlation. I assume users told to type IPv6 addresses will be unhappy regardless.

the point of the above requirement is that the combination of an IPv4 address and a ULA or global IPv6 address, when there is no IPv6 connectivity does not lead to winning user experiences. we need to get host implementations fixed to handle v4/v6 multi-homing well. regardless of 4191 support.

cheers,
Ole

---

From: james woodyatt <[email-masked]>
Date: Mon, 06 Dec 2010 20:40:50 -0800

On Dec 6, 2010, at 16:41, Ole Troan wrote:
> 
> I assume users told to type IPv6 addresses will be unhappy regardless.

Yet, the exact scenario where users type IPv6 addresses into web browser input boxes to configure their IPv6 CPE routers has not been withdrawn as an argument for requiring support for ULA on local interfaces.

Perhaps, we should adopt a new slogan: "We're the IETF. We engineered the Internet. Hopefully, you can get it to work for you too. Good luck."

I'll admit that the smart-grid people are in a bad bind here, but they have alternatives available and the time to pursue them.  They'll eventually sort themselves out.  If we don't get IPv6 for general purpose wide-area use, up and running reliably in the horrifyingly near term, the concerns of the smart-grid people about locally routed home networks are likely to be mooted by the market throwing the whole global IPv6 enchilada into the trash can.

If the only other practical argument for specifying a requirement to support ULA in the *current* draft-- and not the "advanced" one, later-- is to support configuration management interfaces on unconfigured gateways, then I'd say my point about RFC 4191 support shows that it isn't good enough.

> we need to get host implementations fixed to handle v4/v6 multi-homing well. regardless of 4191 support.

More accurately, many in the community seem to be hoping that host implementations will be upgraded at a rapid pace, to run yet-to-be-released versions of system software, which they further hope will be made available to the market, very soon, at prices that most users with existing host implementations are ready to pay immediately, and they are hoping further still that IETF's failure to plan for other contingencies will not be exposed as yet another disastrous error in forecasting on its part.

I do not share these hopes.  In fact, I worry that these hopes are really quite foolish.

---

From: Erik Kline <[email-masked]>
Date: Mon, 6 Dec 2010 21:28:03 -0800

>         Lifetime" field set to zero [RFC4861].

Is there the possibility of a CPE with more than one upstream access
link?  Perhaps rearrange the text from default router to "no default
route", "loses all its default routes", et cetera?

---

From: Fred Baker <[email-masked]>
Date: Mon, 6 Dec 2010 21:41:10 -0800

Certainly there is. Not a Linksys model, but other models.

---

From: Thomas Herbst <[email-masked]>
Date: Mon, 6 Dec 2010 22:11:32 -0800

I'd think the point of the CPE documents would be to come up with rational defaults for those locations without systems administrators.  Those CPE devices should not send to the upstream ISP, but the configurations on the devices aggregation those connections should filter.

Cisco should likely be able to hire an administrator to define and implement the scope of their site.

tom

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Fred Baker
Sent: Monday, December 06, 2010 10:41 AM
To: Mark Baugher
Cc: IPv6 Operations
Subject: Re: [v6ops] ULA & Basic Requirements for IPv6 Customer Edge Routers

                        |Link to upstream
                        |network or provider
                   +----+-----+
                   |          |

---

From: Thomas Herbst <[email-masked]>
Date: Mon, 6 Dec 2010 22:16:22 -0800

James -

What alternatives are you suggesting for the "smart-grid people"?  
Don't use IP?  
Don't use IETF protocols for using IP?
Only enable connectivity if there is a working ISP connection providing a GUA prefix?

tom

---

From: james woodyatt <[email-masked]>
Date: Mon, 06 Dec 2010 22:47:20 -0800

> What alternatives are you suggesting for the "smart-grid people"?  

I don't mean that to be derogatory.  I'm just not well educated about what that community likes to call itself.

> Only enable connectivity if there is a working ISP connection providing a GUA prefix?

One idea that comes to mind is to use tunnel encapsulation at the bastion between the residential 802.1 LAN and the IPv6 over 802.15 sensor network.  Another is an application layer gateway.

I'd think either of those alternatives would have one huge thing going for them over the scenario that the I-D.ietf-v6ops-ipv6-cpe-router authors are describing: they'll work over existing IPv4-only and dual-stack IPv4/IPv6 home networks as they are deployed today, and they don't require an upgrade wave to wash over tens of millions of expensive host implementations for the global IPv6 public Internet to be useful in conjunction with them.

If those alternatives pose equivalently thorny problems for the Internet community, then I don't know what they might be.  Perhaps, someone who knows could offer some details to the list.

---

From: Fred Baker <[email-masked]>
Date: Mon, 6 Dec 2010 22:56:16 -0800

> I don't mean that to be derogatory.  I'm just not well educated about what that community likes to call itself.

I suspect most of them think of themselves as in one sub-category or another - utilities of various kinds, vendors to various markets within the grid, security people, and so on. Yes, they are all working on the Smart Grid, but in the US the grid is highly fragmented (we have over 4000 different utilities, 50 different PUCs not to mention federal regulatory authorities, ...). The grid is in a very real sense where the Internet was in the latter 1980's - it has yet to really develop into a coherent industry or market.

Because of the disparity of sub-markets within the grid, I would be very careful about making any kind of generalizations about its requirements. Tom has tried to express requirements that are likely to apply to the CPE router when the AMI or HAN might put a VPN over it to the utility or a third party. That's very much a point topic.

---

From: Thomas Herbst <[email-masked]>
Date: Mon, 6 Dec 2010 23:39:31 -0800

I'm not sure what the benefit of the tunnel encap would be.

As for the ALG, it breaks end to end security and if I'm doing v6 on the 802.15.4 network, why should I need to do an ALG to communicate in the home? 

Apple and Microsoft both seem to use v6 for their local and wide area applications fairly well; both seem to push a lot of software to me every week or so.

As for timeframes, there are millions of 802.15.4 meters deployed today - 35 million are under contract, globally.  Over 11 million in California alone.  Many of the deployments are underway. 
That said, we won't have the applications or the stacks done until summer 2011.  At the rate at which utilities test and rollout I'd expect some trials in 2011, but volume deployment is likely 
spread across 2012.  

tom

________________________________________
From: james woodyatt [[email-masked]]
Sent: Monday, December 06, 2010 10:47 PM
To: Thomas Herbst
Cc: IPv6 Operations
Subject: Re: [v6ops] ULA & Basic Requirements for IPv6 Customer Edge Routers

---

From: Thomas Herbst <[email-masked]>
Date: Tue, 7 Dec 2010 00:00:23 -0800

I mostly agree w/ Fred.  "Smart Grid" is a marketing term that is mostly useful as an umbrella term.  Usually when I hear engineers use it in a technical discussion I stop them and ask them to speak like engineers.

Here is a short cut to most of the domain terms - 

HAN -> Home Area Network - Premises network usually in residential or small commercial

AMI -> Advanced Meter Infrastructure - an entirely different network used to connect meters to the utility, my company's is v6, more companies are moving in that direction but there are many technologies, protocols, etc

AMR -> Advanced Meter Reading - predated AMI - often one way, often very slow, usually proprietary - focus was replacing the guy with the clipboard

DA -> Distribution Automation - managing the "low voltage" part of the grid.  Often replaces modems or no connectivity 

Transmission -> High voltage, usually longer distances or from large generation

Substation -> switching or other centralized location  for distribution or transmission equipment.  often includes measurement and other grid health sensors for voltage, phase, etc 

Generation -> large power plant

DG/DER -> Distributed Generation/Distributed Energy Resources - small, local power generation (or DER also includes storage) 

There are a bunch of things in the back office.  You could do a massive map with small boxes entirely with three letter acronyms to map a back office.   Meter management, outage management, bill validation, billing, etc etc. 

In this discussion  Don and I are only talking about #1, which is about enabling customers to use XML/HTTP(S)/TCP/IPv6 to get the data out of their own meter.  This will be largely a local application, but if the consumer and the utility both agree, it could be shipped over the consumer's Internet connection to a service that would collect it for the benefit of the user. It is v6 centric because there is no v4 adaptation layer for 802.15.4 and we are rather between protocols for new long lived applications.  v4 is dead but v6 doesn't work yet. 

tom

________________________________________
From: Fred Baker [[email-masked]]
Sent: Monday, December 06, 2010 10:56 PM
To: james woodyatt
Cc: Thomas Herbst; IPv6 Operations
Subject: Re: [v6ops] ULA & Basic Requirements for IPv6 Customer Edge Routers

---

From: Gert Doering <[email-masked]>
Date: Tue, 7 Dec 2010 09:04:57 +0100

Hi,

On Mon, Dec 06, 2010 at 08:46:09PM +0100, Ole Troan wrote:
> this document has not consider dial-on-demand. I would be happy
> to consider it out of scope. in any case doesn't "by default" take
> care of it. in a dial-on-demand mode a CPE has to be configured to
> work differently.

Agree.  Go for it.

Gert Doering
        -- NetMaster

---

From: Ole Troan <[email-masked]>
Date: Tue, 7 Dec 2010 09:35:07 +0100

James,

> If the only other practical argument for specifying a requirement to support ULA in the *current* draft-- and not the "advanced" one, later-- is to support configuration management interfaces on un…

- disconnected network with IPv6 only devices
- device needing only site-local connectivity (and without 'security' to exist in the
  jungle)
- address stability in the home. there will be ISPs that flash renumber the global
  prefix during e.g. network outages, or just to create a product differentiation
  or have short enough lifetimes that the global prefix times out during long outages

the draft states that the device must be able to support ULA's in the sense that it can generate a prefix, apply boundaries correctly and so on. it does not state that it is default on or off.

while it may be entertaining watch a re-run of the site-local/ULA debate we had some years ago. I would rather that you proposed text to the document. what are the changes you suggest given the diffset presented?

> I do not share these hopes.  In fact, I worry that these hopes are really quite foolish.

within the next few months millions of hosts will become multi-homed. we are living in interesting times indeed. a set of host implementation issues was identified (multiple addresses, default route without global connectivity and so on) and we have tried to modify the draft to lessen the chance of "IPv6 breakage". what changes would you like to see; that ULAs were removed completely from the document?

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Tue, 7 Dec 2010 09:20:40 +0100

> route", "loses all its default routes", et cetera?

the basic draft handles only the case of a single uplink.

for the advanced case it would be nice to handle multi-homing. it requires all the solutions pointed at in draft-ietf-v6ops-avoid-ipv6-nat... plus some more. 

cheers,
Ole

---

From: "t.petch" <[email-masked]>
Date: Tue, 7 Dec 2010 12:13:06 +0100

----- Original Message -----
From: "Bjoern A. Zeeb" <[email-masked]>
To: "Ole Troan" <[email-masked]>
Cc: "IPv6 Operations" <[email-masked]>
Sent: Monday, December 06, 2010 6:51 PM

> >         field is set to zero in all Router Advertisement messages it

But what does it mean?  I cannot parse 'no default router'.

'No default route' makes sense, likewise 'no default route' qualified by
where or over which interface the route points, but this text leaves me
puzzled.

Tom Petch

---

From: Ole Troan <[email-masked]>
Date: Tue, 7 Dec 2010 14:24:36 +0100

Tom,

> where or over which interface the route points, but this text leaves me

this term mainly comes from the the dual host/router WAN interface.
see definition of default router in RFC4861.

Default Router List
                   - A list of routers to which packets may be sent.
                     Router list entries point to entries in the
                     Neighbor Cache; the algorithm for selecting a
                     default router favors routers known to be reachable
                     over those whose reachability is suspect.  Each
                     entry also has an associated invalidation timer
                     value (extracted from Router Advertisements) used
                     to delete entries that are no longer advertised.

RFC4191 tries to make a distinction between the best router for the default route and the router least likely to redirect common traffic. I don't think we need to make that distinction here. W-3 does state that router discovery is done. therefore it would follow that if router discovery has failed, then one has no default routers...

that said, I don't think it is too big of a deal and if people think "no default route out the WAN interface" is clearer text than "no default router(s) on its WAN interface" then I'd be happy to change.

cheers,
Ole

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 7 Dec 2010 08:45:10 -0600

Erik, Tom Petch, and anyone else who has asked to change "default router" to "default route", please see my comments below.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Erik Kline
Sent: Tuesday, December 07, 2010 12:28 AM
To: Ole Troan
Cc: Bjoern A. Zeeb; IPv6 Operations
Subject: Re: [v6ops] ULA & Basic Requirements for IPv6 Customer Edge Routers

>route", "loses all its default routes", et cetera?

Note, from day one when Lorenzo from Google raised the ULA issue on Nov. 24th, 2010, lot of folks suggested new text as "default route" and I objected to such text and asked to change to "default router".  I already gave one reason as the fact that the related text is related to IPv6 ND (RFC 4861) and hence use of default router is better because RFC 4861 has no mention of default route.  The second reason is ND has mechanisms to detect a default router has gone down whereas I don't see any specification to detect a default route is not available - maybe there are ad hoc means to detect a default route has gone down, but ND default router is much better because of its NUD and other mechanisms suggested.  The third reason is soon as one uses the term of default route, the immediate question arises, well, what about multiple default routes?  Soon as one has to deal with multiple default routes, one gets into the quagmire of multi-homing.  In contrast, thanks to IPv6 ND, one can use the term of default router(s) because ND is designed to deal with multiple router(s).   Also note multi-homed WAN and LAN on the IPv6 CE Router is not a feature of the Basic IPv6 CE router document being discussed here.  However, it makes sense to discuss Erik's request.

Now, to Erik's specific question, I do like the suggestion, especially since the text Erik suggested does not break anything in the Basic document nor the Advanced document.  Also, note, the same suggestion was made by myself and Wes Beebee.  With Tore's help we put together this text below as of Friday last week.  We have already recommended to Ole to add such text using "all default routers". 

L-16: If the IPv6 CE router has no IPv6 default router on the WAN interface, the IPv6 CE router MUST NOT advertise itself as a default router.  Towards this effect, the router MUST set the Router Lifetime field [RFC 4861] to zero in all Router Advertisement packets it transmits.  If the IPv6 CE router loses all of its IPv6 default routers on the WAN interface(s), it MUST immediately transmit one or more such Router Advertisements.

Hemant

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 7 Dec 2010 08:42:37 -0800 (PST)

Hi Tom,
  Using mesh-under routing would be another solution.
What do you think?

Regards,

Behcet

----- Original Message ----
> From: Thomas Herbst <[email-masked]>
> To: james woodyatt <[email-masked]>
> Sent: Tue, December 7, 2010 1:39:31 AM
> As for the  ALG, it breaks end to end security and if I'm doing v6 on the 
>802.15.4 network,  why should I need to do an ALG to communicate in the home? 
>
> 
> Apple and  Microsoft both seem to use v6 for their local and wide area 
>applications fairly  well; both seem to push a lot of software to me every week 
>or so.
> 
> As for  timeframes, there are millions of 802.15.4 meters deployed today - 35 
>million  are under contract, globally.  Over 11 million in California alone.   
>Many of the deployments are underway. 
>
> That said, we won't have the  applications or the stacks done until summer 
>2011.  At the rate at which  utilities test and rollout I'd expect some trials 
>in 2011, but volume deployment  is likely 
>
> spread across 2012.  
> 
> tom
> 
> 
> 
> One idea that comes to mind is to use tunnel  encapsulation at the bastion 
>between the residential 802.1 LAN and the IPv6 over  802.15 sensor network.  
>Another is an application layer gateway.
> 
> I'd  think either of those alternatives would have one huge thing going for 
>them over  the scenario that the I-D.ietf-v6ops-ipv6-cpe-router authors are 
>describing:  they'll work over existing IPv4-only and dual-stack IPv4/IPv6 home 
>networks as  they are deployed today, and they don't require an upgrade wave to 
>wash over  tens of millions of expensive host implementations for the global 
>IPv6 public  Internet to be useful in conjunction with them.
> 
> If those alternatives  pose equivalently thorny problems for the Internet 
>community, then I don't know  what they might be.  Perhaps, someone who knows 
>could offer some details to  the list.
> 
> 
> --

---

From: "t.petch" <[email-masked]>
Date: Tue, 7 Dec 2010 17:39:07 +0100

----- Original Message -----
From: "Ole Troan" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Bjoern A. Zeeb" <[email-masked]>; "IPv6 Operations"
<[email-masked]>
Sent: Tuesday, December 07, 2010 2:24 PM

Tom,

Default Router List

RFC4191 tries to make a distinction between the best router for the default
route and the router least likely to redirect common traffic. I don't think we
need to make that distinction here. W-3 does state that router discovery is
done. therefore it would follow that if router discovery has failed, then one
has no default routers...

that said, I don't think it is too big of a deal and if people think "no default
route out the WAN interface" is clearer text than "no default router(s) on its
WAN interface" then I'd be happy to change.

<tp>

Thanks for that.  It might be clearer if the text used  'Default Router List'
since that is the defined technical term (which I might have found in a search -
I do find the sheer size of RFC4861 daunting :-).

I suggest "G-4:  By default an IPv6 CE router whose 'Default Router List' has no
entries for its
        WAN interface MUST NOT advertise itself ...  "

Tom Petch
</tp>
cheers,
Ole=

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 7 Dec 2010 11:52:36 -0600

Tom,

The Default Router List in RFC 4861 is meant for a host and thus may not
be a good term to use in the IPv6 CE Router because one operation the
router does is forward packets.  It's only when a network interface of
the IPv6 CE router acquires an IPv6 address, the interface acts as a
host.  The same interface, when sourcing packets acts as a host.  Thus
if we could stick with just "default router(s)" it would be good.

Thanks much.

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of t.petch
Sent: Tuesday, December 07, 2010 11:39 AM
To: Ole Troan
Cc: Bjoern A. Zeeb; IPv6 Operations
Subject: Re: [v6ops] ULA & Basic Requirements for IPv6 Customer Edge
Routers

<tp>

Thanks for that.  It might be clearer if the text used  'Default Router
List'
since that is the defined technical term (which I might have found in a
search -
I do find the sheer size of RFC4861 daunting :-).

I suggest "G-4:  By default an IPv6 CE router whose 'Default Router
List' has no
entries for its
        WAN interface MUST NOT advertise itself ...  "

Tom Petch
</tp>

---

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

On Dec 7, 2010, at 00:35, Ole Troan wrote:
> 
> what changes would you like to see; that ULAs were removed completely from the document?

Not quite.  I'd still like to see an explicit warning, and corresponding requirements, about observed dual-stack host misbehaviors when ULA prefixes are advertised on LAN interfaces without corresponding GUA prefixes.

In other words, I would change the MUST in ULA-1 to a MAY, delete ULA-2 through ULA-4, delete L-2 entirely[*], and delete the second sentence of the first paragraph on page 5.

Also, I would replace what is currently ULA-5 with the following two requirements:

 ULA-x: An IPv6 CE router MUST NOT advertise any ULA prefix using the
	Prefix Information Option [RFC 4861].

 ULA-x: An IPv6 CE router that is delegated or configured with one or
	more ULA prefixes SHOULD advertise itself as a router for them
	using the Route Information Option [RFC 4191].

Additionally, I would insert the following LAN requirements between L-3 and L-4:

   L-x: An IPv6 CE router MUST NOT advertise itself as a default router
	with ValidLifetime greater than zero whenever it has no prefixes
	configured or delegated to it.

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

[*] I would have said it would be sufficient just to remove the parenthetical about ULA addressing from L-2, except I don't see any good reason for the requirement at all.  It seems to imply that IPv6 CE routers MUST NOT act as a bridge between two LAN interfaces, and I can't see what other purpose the requirement might be aiming to support.

---

From: Thomas Herbst <[email-masked]>
Date: Tue, 7 Dec 2010 12:45:25 -0800

Short answer is "maybe". Route over does make ula needed just ithe mesh, but having different mac/phys would still require routing and ula'sunless you beat the 802.15.4 mesh under network into using 802.3 frames. I'd have trouble supporting the approach that all networks have to use Ethernet framing to be supported the home. 
________________________________________
From: Behcet Sarikaya [[email-masked]]
Sent: Tuesday, December 07, 2010 8:42 AM
To: Thomas Herbst; james woodyatt
Cc: IPv6 Operations
Subject: Re: [v6ops] ULA & Basic Requirements for IPv6 Customer Edge Routers

Hi Tom,

Regards,

Behcet

---

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

James,

> In other words, I would change the MUST in ULA-1 to a MAY, delete ULA-2 through ULA-4, delete L-2 entirely[*], and delete the second sentence of the first paragraph on page 5.

the MUST is there so to ensure that a CPE is capable of automatically generating a ULA prefix that is stable across reboots. why do you want that to be a MAY?

delete the sentence about demarcation point? why?

on L-2. misunderstanding of terminology. a LAN interface in this draft is a network layer interface. i.e. it is routed. what you do on the data-link layer is none of our business.

> 	Prefix Information Option [RFC 4861].

that doesn't make sense to me. how are hosts supposed to acquire ULA addresses then?

> 	configured or delegated to it.

ValidLifetime is in the PIO option, if you don't have prefixes you don't have PIO options.
do you mean "router lifetime"?

> 	configured and delegated prefixes are ULA prefixes.

again do you mean Router Lifetime?

> [*] I would have said it would be sufficient just to remove the parenthetical about ULA addressing from L-2, except I don't see any good reason for the requirement at all.  It seems to imply that I…

see above.

your proposal seems to be to remove ULA from the draft and leave a MAY there with the means there to stop it from causing havoc. I think the logical implications of doing that is to provide a stable IPv6 prefix in the home with IPv6 NAT.

cheers,
Ole

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 8 Dec 2010 10:16:26 -0600

James,

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

>Not quite.  I'd still like to see an explicit warning, and
corresponding requirements, about observed dual-stack host misbehaviors
when ULA prefixes are advertised on LAN interfaces without
>corresponding GUA prefixes.

>In other words, I would change the MUST in ULA-1 to a MAY, 

Not possible. The ULA is an IPv6 address type mentioned as global scoped
in RFC 4293 and thus the ULA is a valid address or prefix to be used on
any IPv6 node. 

>delete ULA-2 through ULA-4, 

Why?  If the ULA-1 bullet cannot be removed, then all of the bullets
ULA-2 through ULA-4 make sense.  The ULA MUST be persistent across
reboot of the IPv6 CE router. The ULA prefix must be user configurable
in case of the slightest as heck chance that the ULA prefix turns out to
be a duplicate in the network.  The rest of your points made in this
email have been replied to me Ole.  The summary of my response is that
none of your suggestions need any changes to the Ipv6 CE router
document.

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 8 Dec 2010 10:17:52 -0600

Humble apologies for one typo in the email below.  Replace RFC 4293 with
RFC 4193.

Hemant

-----Original Message-----
Sent: Wednesday, December 08, 2010 11:16 AM

James,

-----Original Message-----

Hemant

---

From: james woodyatt <[email-masked]>
Date: Wed, 08 Dec 2010 09:35:38 -0800

On Dec 8, 2010, at 06:08, Ole Troan wrote:
> [I wrote:]

Because I see no reason to require the capability in every home gateway that wants to comply with the recommendations in this draft.

More to the point, I don't see why the users of AirPort and Time Capsule products, for example, should even be faced with the configuration complexity burden of *choosing* whether to enable the advertisement of ULA prefixes on the LAN bridge, and I'm certainly not going to recommend enabling it by default until I can point engineering product managers at a sensible technical reason to do so.

If hosts on home networks require stable global-scope IPv6 addresses, then they'll need stable globally reachable IPv6 addresses, and I'm sure that service providers will therefore be induced by market demand to provide residential networks with them.  I see no reason for IETF to recommend that all IPv6 CE routers additionally provide ULA addresses, which are not globally reachable, to every home whether they need them or not.

By my reasoning therefore, the draft should be written to give fair warning that the OPTIONAL capability of advertising a ULA prefix is explicitly allowed to IPv6 CE routers, but not REQUIRED.

> delete the sentence about demarcation point? why?

Because ULA are global scope, and service providers should not be constrained from assigning ULA prefixes to routing enclaves that include, but are not limited to, individual subscriber networks.

> on L-2. misunderstanding of terminology. a LAN interface in this draft is a network layer interface. i.e. it is routed. what you do on the data-link layer is none of our business.

That's not at all clear from its entry in the terminology section at the bottom of page 2.

  LAN interface             an IPv6 CE router's attachment to a link in
                             the end-user network.  Examples are
                             Ethernets (simple or bridged), 802.11
                             wireless or other LAN technologies.  An
                             IPv6 CE router may have one or more network

The phrase "Ethernets (simple or bridged)" does not necessarily admit that the ports of an integrated Ethernet switch need not be considered separate LAN interfaces, but can reasonably be regarded as multiple ports attached to the same LAN interface.

I suggest rewording:

  LAN interface		an IPv6 CE router's attachment to a link in
                        the customer edge local-area network.  Examples
			include Ethernet, Wi-Fi and bridging interfaces
			with multiple ports to heterogenous physical
                        layers.  An IPv6 CE router may have more than
			one LAN interface.

> that doesn't make sense to me. how are hosts supposed to acquire ULA addresses then?

You're right.  That's overly aggressive.  I'm sorry.  How about this instead:

  ULA-x: An IPv6 CE router MUST NOT advertise any ULA prefix using the
         Prefix Information Option [RFC 4861] with A=1 unless preceded
         by at least one non-ULA prefix with A=1.

We should also add this requirement for completeness:

  ULA-x: An IPv6 CE router MUST NOT assign any ULA addresses with IA_NA
         or IA_TA options using DHCPv6 [RFC 3315] unless preceded by at
         least one non-ULA address in an IA_NA option.

> again do you mean Router Lifetime?

Yes.  That's what I meant.  Stupid brain.  Need a new one.

> your proposal seems to be to remove ULA from the draft and leave a MAY there with the means there to stop it from causing havoc.

I would characterize my proposal a little differently.  The purpose of the MAY is to make sure the mayhem caused by advertising ULA prefixes is committed where it will do the most creative destruction.

> I think the logical implications of doing that is to provide a stable IPv6 prefix in the home with IPv6 NAT.

I can assure you that my opposition to IPv6/NAT (including NAT66) is as vigorous as it has ever been.  If the chairs will grant me some time at the next meeting to launch another extended and vitriolic rant on the subject to remind the working group that my position remains unchanged, then I'll burn all your hair off.  Wear asbestos underwear.

---

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

everyone--

One of the chairs sent me a message off list, but my response should be directed to the working group.

On Dec 8, 2010, at 09:42, Fred Baker wrote:
> 
> [...] There have been technical reasons advanced on this list for [requiring the capability to advertise ULA prefix on LAN interfaces] - communication within the home in the absence of an upstream that provides the prefix.

Let me review the coexistence problem in question for anyone who has not kept their attention on the whole discussion.

+++ Many dual-stack IPv6/IPv4 hosts that have been configured with this purpose in mind, i.e. with one or more ULA interface addresses and no globally routable IPv6 addresses, are broken for IPv4 service to major Internet applications when AAAA records are advertised in DNS.

+++ Meanwhile, Lorenzo Colitti and Erik Kline at Google tell me they know of home IPv6 CE routers in the wild today, which comply with the current revision of the working group draft by always advertising a ULA prefix, even when no globally routable prefix is delegated.  Always, c.f. the MUST keyword in the draft.

+++ Google as well as other major content providers are citing this coexistence problem as one of the issues preventing them from advertising AAAA records on their front pages on a universal basis.

+++ The fix for this coexistence problem requires universal deployment of one or more of the solutions described in I-D.ietf-6man-addr-select-sol, and IETF work to develop those solutions is still ongoing.

+++ We are several years away from completing a universal deployment on real hosts and networks for any of those solutions, and we need a workaround this coexistence problem before I-D.ietf-v6ops-ipv6-cpe-router reaches WG Last Call.

When considering this coexistence problem, I hope the working group will bear in mind that Apple has been using IPv6 link-local with great success in home networks with IPv4-only service to the Internet for many years.  It coexists perfectly.  It should be considered the best available alternative to the current proposal.

---

From: Fred Baker <[email-masked]>
Date: Wed, 8 Dec 2010 13:01:07 -0800

> +++ Many dual-stack IPv6/IPv4 hosts that have been configured with this purpose in mind, i.e. with one or more ULA interface addresses and no globally routable IPv6 addresses, are broken for IPv4 s…

That is the Happy Eyeballs problem. While it is true that it can be mitigated in the short term in the network, ultimately it has to be solved in the host.

> +++ Meanwhile, Lorenzo Colitti and Erik Kline at Google tell me they know of home IPv6 CE routers in the wild today, which comply with the current revision of the working group draft by always adve…

"Even when" or "at least when"? I should think the ULA could be withdrawn when a global prefix is available. Not sure I want to recommend that (I can think of issues that might arise during the switchover, and the withdrawal is extra functionality that isn't technically required), but it is possible. The point of the ULA is to provide a complex network with a set of prefixes at least when no other prefix is available; if a global prefix is available, there isn't much point.

> +++ Google as well as other major content providers are citing this coexistence problem as one of the issues preventing them from advertising AAAA records on their front pages on a universal basis.

Again, this is the Happy Eyeballs problem. After Happy Eyeballs is fixed, whatever recommendation this spec makes will still be in force. What should the recommendation be at that point in time?

> When considering this coexistence problem, I hope the working group will bear in mind that Apple has been using IPv6 link-local with great success in home networks with IPv4-only service to the Int…

Understood. These are also very limited local networks, with no internal structure.

As has been discussed on this list, there is current requirement for much more complex residential networks, even in IPv4-only networks. For any Cisco employee, for example, a home office (as distinct from a *computer* using a VPN) MUST be on a separate network from the home network; a compadre whose wife works for another company has the same corporate information security requirement for her home office as well. High end homes are beginning to have separate A/V networks. And so on.

This entire discussion went into RFC 3177's recommendation on edge network prefix assignment a decade ago, and relates to draft-ietf-v6ops-3177bis-end-sites as well; we-the-IETF as a community have been recommending to the RIR/LIR community that they enable residential networks among others to have internal structure by allocating prefixes shorter than /64. The implication is that link-local-only addressing within the residential network has issues.

---

From: james woodyatt <[email-masked]>
Date: Wed, 08 Dec 2010 15:24:40 -0800

> Again, this is the Happy Eyeballs problem. After Happy Eyeballs is fixed, whatever recommendation this spec makes will still be in force. What should the recommendation be at that point in time?

Here is the revised summary of my recommendations:

1. Rewrite the terminology glossary definition for "LAN interface" as follows:

2. Delete the second sentence of the first paragraph on page 5, i.e. the one that reads:

   The IPv6 CE router defaults to acting as the demarcation point
   between two networks by providing a ULA boundary, a multicast zone
   boundary and ingress and egress traffic filters.

3. Change the MUST in ULA-1 to MAY, i.e. so it reads as follows:

   ULA-1:  The IPv6 CE router MAY support ULA addressing [RFC4193].
           This document takes no position on whether ULA addressing is
           enabled by default or mechanisms by which users would
           configure it.

4. Delete ULA-2 through ULA-5, i.e. the ones that read:

   ULA-2:  The IPv6 CE router MUST have a ULA prefix that it maintains
           consistently across reboots.

   ULA-3:  The value of the ULA prefix SHOULD be user configurable.

   ULA-4:  By default the IPv6 CE router MUST act as a site border
           router according to section 4.3 of [RFC4193] and filter
           packets with Local IPv6 source or destination addresses
           accordingly.

5. Delete L-2, i.e. the one that reads:

   L-2:   The IPv6 CE router MUST assign a separate /64 from its
          delegated prefix(es) (and ULA prefix if configured to provide
          ULA addressing) for each of its LAN interfaces.

6. Insert the following LAN requirements between the current L-3 and L-4 requirements:

   L-x:   An IPv6 CE router MUST NOT advertise as a default router with
          Router Lifetime greater than zero whenever it has no prefixes
          configured or delegated to it.

   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.

   L-x:   An IPv6 CE router MUST NOT advertise any ULA prefix using the
          Prefix Information Option with A=1 unless preceded in the
          advertisement message by at least one Prefix Information
          Option with A=1 containing a globally routable prefix.

   L-x:   An IPv6 CE router MUST NOT assign any ULA addresses using
          DHCPv6 IA options unless they are accompanied in the same
          IA_NA or IA_TA option by at least one globally routable
          address.

I believe these recommendations are good for the "basic requirements" document under discussion.  When adequate solutions to the problems described in I-D.ietf-6man-addr-select-sol are commonly deployed and readily available, *then*-- and only then-- should IETF consider revising these recommendations to allow for use of ULA prefixes when no globally routable prefix is available.  Perhaps I-D.wbeebee-v6ops-ipv6-cpe-router-bis would be a better vehicle for that.

Here is the revision of the draft sent by Ole Troan that I am using as a baseline for my comments:

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 8 Dec 2010 16:36:37 -0800 (PST)

> 
> I believe these  recommendations are good for the "basic requirements" document 
>under  >discussion.  When adequate solutions to the problems described in  
>I-D.ietf-6man-addr-select-sol are commonly deployed and readily available,  
>*then*-- and only then-- should IETF >consider revising these recommendations to  
>allow for use of ULA prefixes when no globally > routable prefix is  available.  
>

I could not find anything related to ULAs, site-local and the like in
http://tools.ietf.org/id/draft-ietf-6man-addr-select-sol-03.txt.
?
Which section or document are you referring to?

---

From: Fred Baker <[email-masked]>
Date: Wed, 8 Dec 2010 17:58:52 -0800

Well, since the draft has expired...

> Which section or document are you referring to?

I think the key paragraph from RFC 3483 would be:

   The algorithms use several criteria in making their decisions.  The
   combined effect is to prefer destination/source address pairs for
   which the two addresses are of equal scope or type, prefer smaller
   scopes over larger scopes for the destination address, prefer non-
   deprecated source addresses, avoid the use of transitional addresses
   when native addresses are available, and all else being equal prefer
   address pairs having the longest possible common prefix.  For source
   address selection, public addresses [3] are preferred over temporary
   addresses.  In mobile situations [8], home addresses are preferred
   over care-of addresses.  If an address is simultaneously a home
   address and a care-of address (indicating the mobile node is "at
   home" for that address), then the home/care-of address is preferred
   over addresses that are solely a home address or solely a care-of
   address.

If I have several prefixes (and therefore several addressees) and/or my peer does, then I take the cross-product of the sets. For each address pair, the first N bits, for some value of N >= 0, are the same. I count how many bits there are in the common prefix.

For example: if I have addresses

       FD00:1234:5678:9ABC:whatever/128
       2001:0DB8:5678:9ABC:whatever/128
and    2002:1234:5678:9ABC:whatever/128

and my peer has addresses

       FD00:1234:5670::whatever/128
and    2001:0DB8:0678::whatever/128

my ULA and his match in the first 44 bits, my 2001:: address matches his in the first 33 bits, and in all other cases the match is pretty short, on the order of 0..16 bits. The matching algorithm suggests that I try ULA to ULA, as that is the longest match, and if that fails, try 2001:0DB8:5678:9ABC:whatever to 2001:0DB8:0678:9ABC:whatever. What the tables would try to dissuade me from is various forms of translation such as 6to4 etc if I can avoid it.

Where knowing about a ULA could be of value is in funny situations. Imagine if you will that I have two LANs within a ULA and therefore within my own network, but they differ in bit 48 (the most significant bit of the subnet field), and I also have a /56 prefix from my provider. Regardless of how I number the subnets within the /56, the global address prefix will match in at least the first 56 bits, but the ULA will match in only the first 48. So I will try the global address first. There is a line of reasoning that says I should try the ULA instead; if my administration buys into that line of reasoning, it's going to have to play with my RFC 3484 tables to over-ride the longest-match rule.

---

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

James,

let me firstly thank you for providing real text!
(even though I disagree with it. ;-))

>                   layers.  An IPv6 CE router may have more than

the previous definition had "one or more __network__ layer LAN interfaces".
I think that is a better definition.

>   boundary and ingress and egress traffic filters.

I think that's a vital requirement. otherwise a CPE would leak multicast traffic, have to be manually configured to not leak ULA traffic and so. I don't understand the motivation for not having this default. unless you are concerned about the routed home case, where these routers are internal and should not have these boundaries. that case is explicitly outside the scope of this document though.

>           enabled by default or mechanisms by which users would

I think the use of "support" is ambiguous and it means different things to different people (came from my original text.).

I think a CPE implementation MUST be able to generate a ULA prefix automatically, it MUST be able to be a ULA site boundary to avoid leaking.

right now, while most host (and CPE) IPv6 implementations are brittle, it is clear that we do not want ULAs enabled by default. but, I want the code, GUI, "support" to be there in the device. especially since these devices have proven themselves to be much harder to field upgrade than host implementations are.

OK, let me suggest another compromise.

   ULA-1:  The IPv6 CE router MUST be capable of automatically
           generating a ULA prefix according to [RFC4193] if configured to do so.

>           consistently across reboots.

ULA-2: The IPv6 CE router, if configured with a ULA prefix, MUST maintain this
       prefix consistently across reboots.
>           IPv6 default router or not.

keep these as is.

>          ULA addressing) for each of its LAN interfaces.

I don't understand your reasoning behind this proposal.
especially since this breaks use of the global prefix in the home.

>          configured or delegated to it.

agree. let's see if we can get this requirement incorporated somewhere.

>          configured and delegated prefixes are ULA prefixes.

that's covered already I believe.

>          Option with A=1 containing a globally routable prefix.

disagree. that prohibits anyone from using ULAs.

>          IA_NA or IA_TA option by at least one globally routable

disagree.

> I believe these recommendations are good for the "basic requirements" document under discussion.  When adequate solutions to the problems described in I-D.ietf-6man-addr-select-sol are commonly dep…

iff we were to go down this route, I'd much rather that we were silent on the topic and removed any reference to ULAs. that way at least we don't create future conflicts.

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Thu, 9 Dec 2010 19:23:27 +0100

>> In other words, I would change the MUST in ULA-1 to a MAY,

+1.

>> delete ULA-2 through ULA-4, delete L-2 entirely[*], and delete the second sentence of the first paragraph on page 5.
> 

What should be sufficient, for an IPv6 network to work without Internet access, is something at least as simple as RFC 1918 (not as complex as ULAs). 
For this, a standard local prefix like fc00::/16 would do:
- Like ULAs, it starts with the fc00::/16, the reserved prefix for Local IPv6 unicast addresses.
- It cannot interfere with ULAs because all ULAs start with fd00::/8.
- Other uses of fc00::/7 aren't precluded.

In fact, the only use of IPv6 local addresses I have heard of was on a large scale network using a short prefix starting with fc00::/8.
Unfortunately I have no reference to provide (in my recollection, it was in some US government network, presented in a Google IPv6 Implementers conference in April 2009)

PROPOSAL:
- The MUST would be only for "a private prefix advertisement when the CE has no global prefix*.
- By default it MUST be fc00::/7.
- It MAY be a ULA if ULAs are supported and if requested by configuration.

Regards,
RD

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Dec 2010 16:44:45 +1300

I was away for 4 days, so excuse me chiming in late and
responding to early messages in the thread, but I think
they are the most to the point:

> On Dec 5, 2010, at 4:06 PM, james woodyatt wrote:
...
> Why it's so important that they speak up?  It would be interesting to know if some uses or non-use of ULAs matters to them, but I doubt that it does.  ULAs support routed home networks for traffic…

Exactly. The existing text is in there because it describes the previously
established consensus to (a) accept ULAs as a basic property of IPv6 and
(b) to require CPEs to support them.

I would strongly object to changing this, especially as an AUTH48 change.
At this point, I think we should insist on seeing a complete new draft
and a new Last Call if there is to be any substantive change whatever.
Otherwise, there would be a clear IETF process violtaion.

On 2010-12-06 14:30, Hemant Singh (shemant) wrote:
...
> default or mechanisms by which users would configure it.]

That would not be unreasonable, if agreed by WG consensus. I'm sure that
some kind of best practice will emerge with experience; it's too soon
to tell.

On 2010-12-06 18:09, Randy Bush wrote:
...
> burn a bit of global address space into the devices.

I don't see any difference in practice between that and a ULA
prefix that is generated on factory-reset of the CPE. That's
what we invented ULAs for in the first place, and so far we've managed
to avoid the waste-of-space of a central ULA prefix registry.

   Brian

---

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

>> burn a bit of global address space into the devices.

If I understand the question (not sure), the need is for a fixed prefix that can be used when a CPE doesn't get a global prefix from the Internet.
As I proposed in another mail, fc00::/16 would do that *without borrowing a globally routable prefix*.
The reason is that:
- fc00::/7 is already reserved for local addressing
- starting with fc00::/8 ensures that it doesn't interfere with ULAs (they all start with fd00::/8)
- by taking a /16 starting with fc00::/8, plenty of room is left for other types of local prefixes that may prove useful in the future (neither ULAs nor this reserved prefix).

Note that this prefix provides in IPv6 the equivalent of RFC 1918 in IPv4  with the advantage that there is only one prefix instead of 3.

Note that enterprises that want to anticipate network mergers can still use ULAs.
The advantage that unmanaged networks (for which enterprise mergers isn't a concern) can have by default this well known reserved prefix. 

> prefix that is generated on factory-reset of the CPE.

A factory reset, as opposed to another reset, is already too complex a concept for many users.
Keeping always the same local prefix is a useful simplification for them. 

> That's

This property of ULAs remains for those that are knowledgeable enough to use them.

Regards,
RD

---

From: Mark Baugher <[email-masked]>
Date: Fri, 10 Dec 2010 10:21:35 -0800

> The advantage that unmanaged networks (for which enterprise mergers isn't a concern) can have by default this well known reserved prefix. 

This is not true for some uses, such as those that combine the home networks of two households into a single, private network.

Mark

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 10 Dec 2010 11:09:32 -0800

On 12/10/10 10:21 AM, Mark Baugher wrote:
>> The advantage that unmanaged networks (for which enterprise mergers
>> isn't a concern) can have by default this well known reserved
>> prefix.
> 
> This is not true for some uses, such as those that combine the home
> networks of two households into a single, private network.

Merging two households is a fractal representation of merging to
enterprises.

generically but in the (first person) consider the following use cases:

o we have multiple cpe with different numbering plans (And a branch office)
o I'd like to be able to use my girlfriend's printer.
o likewise she'd like to control the myth-tv remotely.
o the google-tv needs to be able to reach the nas box.
o we have vpn's pointing in different directions into different enterprises.
o somehow through all of this the ip-phone needs to stay working
otherwise no 911.
o we'd like the music streamer in my condo to continue working using the
nas box that moved to her house.

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

---

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

On 2010-12-10 22:05, Rémi Després wrote:
...
> Keeping always the same local prefix is a useful simplification for them. 

Exactly. So people who don't know how to perform a factory reset will keep
the same prefix for ever. No problem. No difference from an arbitrary
prefix of any other kind. ULAs are simple things.

   Brian

---

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

Joel,

> nas box that moved to her house.

How is this different from the bog standard IPv6 situation of running
several global prefixes on the same network? I don't see that ULAs
are special.

draft-troan-multihoming-without-nat66 applies, surely?

    Brian

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 10 Dec 2010 15:29:37 -0800

> several global prefixes on the same network? I don't see that ULAs

It's not, my goal was a strawman of real use cases associated with
devices found in the home. I did not advocate for a particular outcome
in so doing.

> draft-troan-multihoming-without-nat66 applies, surely?

certainly.

---

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

Hi,

Look in draft-ietf-6man-rfc3484-revise-01

Tim