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

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

-----Mensaje original-----
De: Fred Baker <fredbaker.ietf@gmail.com>
Responder a: <fredbaker.ietf@gmail.com>
Fecha: domingo, 18 de junio de 2017, 1:07
Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
CC: IPv6 Operations <v6ops@ietf.org>
Asunto: Re: [v6ops] New Version Notification for draft-baker-v6ops-cpe-autoconfigure-00.txt

    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 <jordi.palet@consulintel.es> wrote:
    > 
    > 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 <v6ops-bounces@ietf.org> en nombre de Fred Baker <fredbaker.ietf@gmail.com>
    > Responder a: <fredbaker.ietf@gmail.com>
    > Fecha: sábado, 17 de junio de 2017, 23:21
    > Para: IPv6 Operations <v6ops@ietf.org>
    > Asunto: Re: [v6ops] New Version Notification for draft-baker-v6ops-cpe-autoconfigure-00.txt
    > 
    >    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, internet-drafts@ietf.org 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
    >> 
    > 
    >    _______________________________________________
    >    v6ops mailing list
    >    v6ops@ietf.org
    >    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.
    > 
    > 
    > 
    > _______________________________________________
    > v6ops mailing list
    > v6ops@ietf.org
    > 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.