Subject: Re: [v6ops] New Version Notification for draft-baker-v6ops-cpe-autoconfigure-00.txt

From: Fred Baker <[email-masked]>
Date: Sat, 17 Jun 2017 14:21:09 -0700

In discussion with John Brzozowski, he expressed a concern that CPEs don't come "out of the box preconfigured for IPv6" as they often do for IPv4. I had a recent experience with a new router at my home that made the point in my mind; IPv6 was an "advanced configuration", and the difference between "auto-configure" and "auto-detect" was a little lost on me. 

So I have a question. Do we need to spell this out for CPE vendors? I have spliced together a draft on the topic. I'd welcome comments that might improve it, especially if I have something egregiously wrong. Second, I'm curious whether the working group thinks we need this.

Your thoughts?

> On Jun 17, 2017, at 2:14 PM, [email-masked] wrote:
> 
> 
> A new version of I-D, draft-baker-v6ops-cpe-autoconfigure-00.txt
> has been successfully submitted by Fred Baker and posted to the
> IETF repository.
> 
> Name:		draft-baker-v6ops-cpe-autoconfigure
> Revision:	00
> Title:		Requirements for a Zero-Configuration IPv6 CPE
> Document date:	2017-06-17
> Group:		Individual Submission
> Pages:		6
> URL:            https://www.ietf.org/internet-drafts/draft-baker-v6ops-cpe-autoconfigure-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-baker-v6ops-cpe-autoconfigure/
> Htmlized:       https://tools.ietf.org/html/draft-baker-v6ops-cpe-autoconfigure-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-baker-v6ops-cpe-autoconfigure-00
> 
> 
> Abstract:
>   This note is a breif exploration of what is required for a CPE to be
>   auto-configurable from the perspective on an ISP or other upstream
>   network.  It assumes that the CPE may also be IPv4-capable (probably
>   using NAPT), but that the requirements for that are well understood
>   and need no further specification.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 17 Jun 2017 23:53:24 +0200

Hi Fred,

I just read the document and I think is something needed.

In fact, it should be one requirement to be a should or must in the RFC7084-bis. Not sure if others agree and if there is some way to “sync” a reference in the RFC7084-bis with an individual I-D (I got an input previously to remove that), until it becomes an RFC (if approved), or it means “holding” it …

Of course, if there is no opposition in the WG, this may be approved and go to the last call quicker than the RFC7084-bis, so not being an issue.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Fred Baker <[email-masked]>
Responder a: <[email-masked]>
Fecha: sábado, 17 de junio de 2017, 23:21
Para: IPv6 Operations <[email-masked]>
Asunto: Re: [v6ops] New Version Notification for draft-baker-v6ops-cpe-autoconfigure-00.txt

    
    Your thoughts?

    > until the htmlized version and diff are available at tools.ietf.org.
    
    _______________________________________________
    v6ops mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/v6ops

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Fred Baker <[email-masked]>
Date: Sat, 17 Jun 2017 16:07:02 -0700

In which case 7084-bis could refer to it. I tend to worry about having a requirements document go into algorithms, which this does (I think it's an obvious algorithm that doesn't need spelled out, but nobody seems to have realized that when they did their implementations).

And the draft is probably imperfect in some way.

> On Jun 17, 2017, at 2:53 PM, JORDI PALET MARTINEZ <[email-masked]> wrote:
> 
> Hi Fred,
>

---

From: David Hooton <[email-masked]>
Date: Sun, 18 Jun 2017 07:18:12 +0000

On 18/6/17, 7:21 am, "v6ops on behalf of Fred Baker" <[email-masked] on behalf of [email-masked]> wrote:
    In discussion with John Brzozowski, he expressed a concern that CPEs don't come "out of the box preconfigured for IPv6" as they often do for IPv4. I had a recent experience with a new router at my home that made the point in my mind; IPv6 was an "advanced configuration", and the difference between "auto-configure" and "auto-detect" was a little lost on me. 

You’re not the only one.
    
    So I have a question. Do we need to spell this out for CPE vendors? 

Yes. It needs to happen. 

On 18/6/17, 7:53 am, "v6ops on behalf of JORDI PALET MARTINEZ" <[email-masked] on behalf of [email-masked]> wrote:
    I just read the document and I think is something needed.

Agreed.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 18 Jun 2017 11:33:47 +0200

Some detailed comments:

and allocate IPv6 /64 prefixes for each of its interior subnets
      using the IPv6 Prefix Options for DHCP [RFC3633].

I think it is needed to state something about a prefix shorter than /64 is allocated to the “LAN-side” to ensure that the CPE, either in an unmanaged way (maybe HNCP, not sure if something else may be considered), or managed by the “customer”, so than a /64 can be assigned to each possible subnet/VLAN/SSID/whatever, or even shorter prefixes to downstream routers (for instance a /48 from the ISP broken in /56 inside the network other routers and /64 for each LAN).

Same question here: 4.  Given an upstream interface and a delegation of prefixes to use
       downstream, it should

       *  subdelegate a /64 prefix to each downstream interface

It seems to only support /64 to downstream interfaces, unless you read “Prefix delegation”, may be some alternative text may clarify it at an earlier point.

At “Expected Behavior”, maybe is worth to mention that in case native IPv6 access is not available, and transition mechanisms are supported, the CPE must try con configure one of them. Probably after “waking up” each possible transition mechanism, the same “loop” as you described in the “Expected Behavior” section, must be tested to be able to get “IPv6 up and running”.

Finally, if the access is IPv6-only, it may be expected some “IPv4 as a service” support, and then RFC8026 may be helpful to configure it. I know you mention in the intro that IPv4 is specified somewhere else, but in this case, is not “native IPv4”, but a “service” by means of and IPv6 network.

Regards,
Jordi

---

From: Tim Chown <[email-masked]>
Date: Mon, 19 Jun 2017 09:43:22 +0000

Hi,

> On 17 Jun 2017, at 22:21, Fred Baker <[email-masked]> wrote:
> 

It would be great if a document like this were not needed, but anecdotal evidence suggests that it is. 

Tim

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 19 Jun 2017 13:47:26 +0000

> Your thoughts?

Here are a number of my thoughts.

BBF described automated IPv6 configuration for telco-procured CE routers in TR-124 (https://www.broadband-forum.org/technical/download/TR-124_Issue-5.pdf) in Annex A. A.1 is for PPPoE and A.2 is for native IPv6. I don't see a need for this draft wrt CE routers my company procures, because auto-config advice already exists.

The BBF flow has simultaneous RS and DHCPv6 solicitation. This is at odds with what you suggest. Simultaneous and sequential are both allowed by RFC 7084. I realize many cable providers have expressed a preference for sequential RS and DHCPv6 solicit, but many telcos have expressed a preference for simultaneous. But both models work in cable and telco environments.

The BBF flow mandates requesting IA_PD, while you propose it as a very weak MAY. Note that RFC 7084 mandates support for IA_PD. If you really want auto config of a CE router, this is the only way I know of to do it. I don't see that a MAY IA_PD requirement would ever result in auto configuration. Only a MUST will.

BBF also supports auto-configuration via the unnumbered model where the RA does not include an Autonomous prefix and there is no offered IA_NA. RFC 7084 allows for the unnumbered model. You make no mention of the unnumbered model. I don't know how prevalent the unnumbered model is, though.

Sub-delegating into a home network with many subnets (which means the topology is likely to be unpredictable and arbitrary) really needs HNCP and not IA_PD. In the absence of HNCP, any algorithm to try to calculate the correct number of needed prefixes doesn't make sense to me. In other words, I wouldn't trust a calculation that resulted in a need for 17 prefixes, in the absence of HNCP.

As a final note, I have a pet peeve wrt "CPE". CPE = *all* Customer Premises Equipment, including set-top boxes, home automation gateways, VoIP ATAs, etc. Unless this doc is for auto-config of STBs and the rest, could I convince you to use "CE Router"? "CER" can be used as an abbreviated form.
Barbara

---

From: Fred Baker <[email-masked]>
Date: Mon, 19 Jun 2017 13:44:29 -0700

> BBF described automated IPv6 configuration for telco-procured CE routers in TR-124 (https://www.broadband-forum.org/technical/download/TR-124_Issue-5.pdf) in Annex A. A.1 is for PPPoE and A.2 is fo…

Thanks. TR-124, of course, applies to DSL routers procured by companies and used in managed router services. It doesn't apply to Cable Modem routers, nor to routers used in open source networks such as Jordi discusses in his 7084-bis.

Are you objecting to the draft, or simply stating that it covers material already covered for DSL routers used in ISP managed service?

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 19 Jun 2017 22:39:52 +0000

> Thanks. TR-124, of course, applies to DSL routers procured by companies and
> used in managed router services. It doesn't apply to Cable Modem routers,
> nor to routers used in open source networks such as Jordi discusses in his
> 7084-bis.
> 
> Are you objecting to the draft, or simply stating that it covers material already
> covered for DSL routers used in ISP managed service?

TR-124 is used by telco ISPs for a variety of procured CE routers, including those with and without a DSL modem or G.fast or PON ONT interface. Some just have Ethernet WAN. It is not limited to DSL WAN interface. Note that the Annex A procedures assume nothing more than Ethernet MAC to the WAN.

I would object to anything that suggested the auto-configuration processes that may be used by cable providers are somehow superior, better, preferred, or recommended over auto-config procedures used by non-cable providers.

There are numerous "correct" ways to do IPv6 auto-config. Describing just one, and then making it normative in a 7084-bis would not be something I would favor. If cable providers want to get together and say "FYI, here is a way some cable operators like to do auto-config", I would not object. Or if v6ops wanted to do a draft of "here are several possible and valid ways to do auto-config that would be RFC7084-compliant -- pick any one of them because the only requirement for interoperability is RFC7084", I would be happy to participate.
Barbara

---

From: "Mukom Akong T." <[email-masked]>
Date: Tue, 20 Jun 2017 21:50:05 +0400

On 18 June 2017 at 01:21, Fred Baker <[email-masked]> wrote:

> IPv6 was an "advanced configuration", and the difference between
> "auto-configure" and "auto-detect" was a little lost on me.
>

Agree and sometimes the options offered in the config screens as just
bizare (e.g. Native and 6to4 as IPv6 connection types)

>
> So I have a question. Do we need to spell this out for CPE vendors? I have
> spliced together a draft on the topic. I'd welcome comments that might
> improve it, especially if I have something egregiously wrong. Second, I'm
> curious whether the working group thinks we need this.
>
> Your thoughts?
>

>From the document,

[snip]

It may offer a DNS service using a provider such as OpenDNS, Google

   Public DNS, Amazon Route 53, or some other such service, or relay the

   address of an ISP-provided DNS server.

[/snip]

In the context of a home, I’d think DNS service should be a MUST and here’s
why

   - the typical home user is not sophisticated enough to configure
   anything once the provider has installed it
   - they currently don’t have to configure anything in IPv4
   - making them have to configure resolvers for IPv6 puts IPv6 on a
   different, harder path than IPv4 and they wouldn’t even know where to start
   - This is particularly important in IPv6 only where there wouldn’t even
   be an IPv4 DNS resolver to use

[snip]

Similarly, the stated goal requires that upstream, the CPE must

   presume that it will be required to solicit and observe a Router

   Advertisement [RFC4861], and

   o  learn an upstream DHCPv6 server address,

   o  either autoconfigure [RFC4862] its upstream address or derive one

      using DHCPv6 [RFC3315],

   o  potentially learn an DNS server address from an RDNSS [RFC4339] or

      from DHCPv6,

   o  and allocate IPv6 /64 prefixes for each of its interior subnets

   Given that, it is in a position to offer IPv6 services in the

   residential/SOHO network depending on the upstream IPv6 capabilities.

[/snip]

What if we replace the first two bullet points with

   - configure its WAN interface with one or more GUA addresses using
   whatever mechanism it negotiates with the ISP’s 'serving' device/

In EXPECTED behavior, I’d favour a MUST for IA_PD because it presents the
only option for provisioning devices in the network if NAT is not an option

Lastly, how is the CPE to know what to request ask “Length for this prefix
in bits" with its IA-PD request?

-- 

Mukom Akong T.

LinkedIn:Mukom <https://www.linkedin.com/in/mukom>  |  twitter:
@perfexcellent

------------------------------------------------------------------------------------------------------------------------------------------
“When you work, you are the FLUTE through whose lungs the whispering of the
hours turns to MUSIC" - Kahlil Gibran
-------------------------------------------------------------------------------------------------------------------------------------------

---

From: Gert Doering <[email-masked]>
Date: Tue, 20 Jun 2017 20:25:16 +0200

Hi,

> So I have a question. Do we need to spell this out for CPE vendors? 

Yes.

If it's not mandated by telcos that buy large numbers of CPE (or CERs),
vendors will ship "what they think the market wants", and that currently
seems to be "it will do IPv4 + NAT".

German computer magazine C't tests every new router for "will it work
with IPv6 on a dual-stack connection to Deutsche Telekom" - which is 
one of the dominant players in the market here - and half the devices 
fail.  Today.  Many years after DT started to turn on IPv6 by default
on all new customer DSL lines.

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

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

---

From: "Mukom Akong T." <[email-masked]>
Date: Wed, 21 Jun 2017 05:16:12 +0400

On 18 June 2017 at 01:21, Fred Baker <[email-masked]> wrote:

> IPv6 was an "advanced configuration",

I think this is a result of the mentality (which you and John correctly
identify) that "this IPv6 thing won't work out of the box like IPv4 + NAT",
so let's put it under some "Advanced" menu where we can keep it disabled
(or crippled) by default unless a geeker user goes in there to configure it.

If we end up with a document that makes IPV6 work out of the box, that
mentality will go away and we can just have similar configuration tabs (or
dialog box sections) - one for IPv4 and another nearly identical one for
IPv6

-- 

Mukom Akong T.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 22 Jun 2017 00:52:39 +0900

On Mon, Jun 19, 2017 at 10:47 PM, STARK, BARBARA H <[email-masked]> wrote:

> The BBF flow has simultaneous RS and DHCPv6 solicitation. This is at odds
> with what you suggest. Simultaneous and sequential are both allowed by RFC
> 7084. I realize many cable providers have expressed a preference for
> sequential RS and DHCPv6 solicit, but many telcos have expressed a
> preference for simultaneous.

IIRC the preference for simultaneous was for telco environments where the
device had to emit a packet before the network would see it. The concern
was that because the device only sent three RSes on startup, if those three
RSes were dropped then it would never get an RA.

That concern is largely mitigated by resilient RS, which is now available
on fairly recent versions of Linux (and was backported to Android kernels
all the way back to 3.10, so CPE vendors can use it on older kernels too).

> The BBF flow mandates requesting IA_PD, while you propose it as a very
> weak MAY. Note that RFC 7084 mandates support for IA_PD. If you really want
> auto config of a CE router, this is the only way I know of to do it. I
> don't see that a MAY IA_PD requirement would ever result in auto
> configuration. Only a MUST will.

+1. An IPv6 CE router MUST do IA_PD otherwise it's not an IPv6 CE router.
It does not need to do DHCPv6 address assignment on the WAN interface
unless the ISP requires that for management purposes.

> BBF also supports auto-configuration via the unnumbered model where the RA
> does not include an Autonomous prefix and there is no offered IA_NA. RFC
> 7084 allows for the unnumbered model. You make no mention of the unnumbered
> model. I don't know how prevalent the unnumbered model is, though.
>

As a data point, I think most of the FTTH deployments here in Japan use the
unnumbered model.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 22 Jun 2017 01:06:17 +0900

On Sun, Jun 18, 2017 at 6:21 AM, Fred Baker <[email-masked]>
wrote:

> In discussion with John Brzozowski, he expressed a concern that CPEs don't
> come "out of the box preconfigured for IPv6" as they often do for IPv4. I
> had a recent experience with a new router at my home that made the point in
> my mind; IPv6 was an "advanced configuration", and the difference between

We have already spelled it out in RFC 7084, which contains more detail than
this draft.

I don't think this document is a good idea because it oversimplifies what
an IPv6 router needs to do. Critical things that will result in outages and
broken connectivity are missing, and if an implementer just read this
document and built a product, it would be a broken product. Here are some
examples of things that need to be done in order to provide reliable
connectivity.

   1. The downstream RA MUST report an MTU that's <= the MTU of the WAN
   interface
   2. When the WAN default route is lost, the router MUST send out
   zero-lifetime RAs on the LAN
   3. A multi-subnet router MUST send out RIOs if cross-subnet traffic is
   desired.
   4. When the WAN is renumbered, the changes MUST be reflected in the LAN
   RAs.

Based on very recent personal experience, these things are not only
important, completely non-obvious to developers who have build an IPv4-only
product (even an upmarket one), and also very hard to implement in the
typical "just bolt together dnsmasq and dhcpcd" style of implementation
that many of these CE routers use. The open-source ecosystem just isn't
there yet. Example: dnsmasq can't do #1, #2 and #3 at all.

The best advice that we can give to CE router manufacturers is:

   1. Please implement IPv6.
   2. Follow RFC 7084.
   3. Send your box to UNH IOL (or any IPv6-ready logo test lab) repeatedly
   until it passes.

I'm not even sure that #1 is good advice until more people have done #3 and
the open source ecosystem has caught up - unless the plan is to have the
routers occasionally provide broken connectivity and wallpaper over the
problem with happy eyeballs (aka, kick the can down the road until such
time as we need to take away IPv4).

---

From: Fred Baker <[email-masked]>
Date: Wed, 21 Jun 2017 10:04:27 -0700

> On Jun 21, 2017, at 9:06 AM, Lorenzo Colitti <[email-masked]> wrote:
> 
> We have already spelled it out in RFC 7084, which contains more detail than this draft.

And there I disagree. I'm happy to add more to the draft; it's an initial sketch. However, we have seen several comments to the effect that 7084 and TR-124 are not resulting in product that works "out of the box". In private email, Ole Troan suggests that I go implement something that works "out of the box" in an open source product, perhaps OpenWRT, and that's good. But I'll argue that before we do that, we should know what algorithm to implement.

What we have spelled out in RFC 7084, and BBF has spelled out in TR-124, is that the product must implement a list of specifications. It does not say that it has to work out of the box, and it doesn't say how to accomplish that goal if it is a goal.

I am starting to put together slides for IETF 99, and first making the case. You may be interested to review them. You may find the file, in its present state, at https://www.dropbox.com/s/bczr0dvukxn92w5/CPE%20Router%20Auto-configuration.pptx?dl=0. I don't want to call out a specific vendor in the case, but it's hard to avoid the name on their screen shots, so in the slides where I take screen shots of the configuration steps do us all a favor and ignore the name of the vendor - it's not important. What is important is what is required to actually turn basic IPv6 service on, in the router in my home, which was fully IPv4+NAPT-capable when I came to the first screen. It had to be, because it asked me to upgrade its firmware over my existing IPv4 network, and I was logged into it using IPv4.

And what is VERY important is that the router is, as far as I can determine, both RFC 7084 and TR-124 compliant. Being RFC 7084 and TR-124 compliant doesn't result in it selecting correctly among SLAAC and DHCP on the LAN and WAN interfaces when attached to a random upstream network.

Note that this note is specifically in response to a request from John Brzozowski that the IETF make his IPv6 deployment in Comcast easier. My comment to him on the call was that he could specify in his RFP the things that would accomplish the role, and he wanted something in the IETF. I have asked for his comments on this and he has not replied, so I'm happy to be told I misunderstood him, but I understand him to be saying that the difficulty of getting routers to actually work with his network is something he wants to address.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 21 Jun 2017 17:30:47 +0000

The BBF flow has simultaneous RS and DHCPv6 solicitation. This is at odds with what you suggest. Simultaneous and sequential are both allowed by RFC 7084. I realize many cable providers have expressed a preference for sequential RS and DHCPv6 solicit, but many telcos have expressed a preference for simultaneous.

IIRC the preference for simultaneous was for telco environments where the device had to emit a packet before the network would see it. The concern was that because the device only sent three RSes on startup, if those three RSes were dropped then it would never get an RA.

That concern is largely mitigated by resilient RS, which is now available on fairly recent versions of Linux (and was backported to Android kernels all the way back to 3.10, so CPE vendors can use it on older kernels too).

<bhs> I was recalling this happened because a certain guy, named Ole Troan, convinced us it was more efficient and there was no reason to wait. Without IA_PD, the connection is fairly useless. If know you need it, why wait. I recall no discussion of the access network architecture people asking for it, and can’t find this mentioned in TR-177 or TR-187 (access network architecture IPv6 docs).
Barbara