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

"Mukom Akong T." <mukom.tamon@gmail.com> Tue, 20 June 2017 17:50 UTC

Return-Path: <mukom.tamon@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90CB3129496 for <v6ops@ietfa.amsl.com>; Tue, 20 Jun 2017 10:50:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjU01Z-jhmJK for <v6ops@ietfa.amsl.com>; Tue, 20 Jun 2017 10:50:47 -0700 (PDT)
Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 837E5124D85 for <v6ops@ietf.org>; Tue, 20 Jun 2017 10:50:46 -0700 (PDT)
Received: by mail-it0-x232.google.com with SMTP id g184so18868113ita.0 for <v6ops@ietf.org>; Tue, 20 Jun 2017 10:50:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sN/OA4chaaDmfDQQ/de8PBSJYyc1n/UqfOa/mtGzYPQ=; b=k8xgB2rj9miiCNB5Nw8g9dOq02nVqGdi8PNDVh3URIFZcPgzSerujD+oYMoo/ed9WV gY3w5Q0rF1OPqqXh1AW8oKA8j7Skpuk7Tu7SdrgO5zE7dtzFumV5tmNPNqXw47M/JG+P taLq5e44aywTTiCgSpEwGvehqqIT0A/W9MTGVGIvwdxLKqOKcdlgPTcSKrGp1XkEaDCy A28JcciW2AkMTz69+ZaX/Hf5kJiJ/Mcrv+yS4UfmM8QdaZm/XMgictzZUDYAoYfUD/Ur w+U5od0Tjcup8+wnAnum8QCHAsCCkaUAMbLS6+7dZ4VAJPCpBUkfKCE6Xg8VYGKL5nk6 OLXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sN/OA4chaaDmfDQQ/de8PBSJYyc1n/UqfOa/mtGzYPQ=; b=oKQ/0gS/TlgdQgtE17k/qW8AzKRP2P+/G4SyY39tB0UVO750WSSdp8qd93fs8eZB2E W9LBtA43MsFZ87YM6UnT8ZtrHc81MVPr/YC0Iu14zAWtDETEk9h7na5+HWAI8mPpVMSs C5uUWcb69srpDo2fTdvGaekQRbIhkGJAqMiNkiTK+ljKhDVB43vRQH5kj7jTAs3akfRl sevnHLBipSdqxkz+swg69I6JgLsVj7qp1CYG90yo2DXGSz2yR2Qlug1k+4FgVCNNiIki uLpipQ5iZGinQPP74zTzXsyZ8sKzUfZnYRC3LBEIYgGE+q/IRbeLjsD8n1JSfYHGSNRw NCWA==
X-Gm-Message-State: AKS2vOyLHc7l7Klo+rt/rFHuFvNM1vrV4CJfKm/A3p4bjCHqfoi3vY34 0jnOCAqeUMOmrvPIIqGg8zscpTUxxQ==
X-Received: by 10.36.29.147 with SMTP id 141mr4631290itj.83.1497981045852; Tue, 20 Jun 2017 10:50:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.27.131 with HTTP; Tue, 20 Jun 2017 10:50:05 -0700 (PDT)
In-Reply-To: <334ACBB6-C438-410B-81D7-49269AC51004@gmail.com>
References: <149773408722.14141.1243099989313191246.idtracker@ietfa.amsl.com> <334ACBB6-C438-410B-81D7-49269AC51004@gmail.com>
From: "Mukom Akong T." <mukom.tamon@gmail.com>
Date: Tue, 20 Jun 2017 21:50:05 +0400
Message-ID: <CAHDzDLC9bx5E5JaSQnjFADmSedfM6aCVVDny2p4pvQAm-7ZEEg@mail.gmail.com>
To: Fred Baker <fredbaker.ietf@gmail.com>
Cc: IPv6 Operations <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="001a1143db6a1e76fd055267e483"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/kRQFmYwg3RtMSHfwjXQ7O6Uy8Io>
Subject: Re: [v6ops] New Version Notification for draft-baker-v6ops-cpe-autoconfigure-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Jun 2017 17:50:53 -0000
X-List-Received-Date: Tue, 20 Jun 2017 17:50:53 -0000

On 18 June 2017 at 01:21, Fred Baker <fredbaker.ietf@gmail.com> 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

      using the IPv6 Prefix Options for DHCP [RFC3633].


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