IETF Logo Mail Archive

Re: [v6ops] Turning on IPv6 Routers

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 21 July 2017 11:24 UTC

Return-Path: <mcr@sandelman.ca>
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 AFF7B131483; Fri, 21 Jul 2017 04:24:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 Zo57jjBSgS83; Fri, 21 Jul 2017 04:24:47 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A824B129B7F; Fri, 21 Jul 2017 04:24:47 -0700 (PDT)
Received: from dooku.sandelman.ca (dhcp-9cfb.meeting.ietf.org [31.133.156.251]) by relay.sandelman.ca (Postfix) with ESMTPS id 825F31F8F6; Fri, 21 Jul 2017 11:24:46 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 1851C1638; Fri, 21 Jul 2017 13:24:37 +0200 (CEST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Fred Baker <fredbaker.ietf@gmail.com>
cc: IPv6 Ops WG <v6ops@ietf.org>, 6man WG <ipv6@ietf.org>
In-reply-to: <28757A47-53D8-459E-B76D-D5D5DE3D5897@gmail.com>
References: <28757A47-53D8-459E-B76D-D5D5DE3D5897@gmail.com>
Comments: In-reply-to Fred Baker <fredbaker.ietf@gmail.com> message dated "Thu, 20 Jul 2017 16:22:56 +0200."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Fri, 21 Jul 2017 13:24:37 +0200
Message-ID: <7172.1500636277@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/3oFqRQCteIz59e3qvNGnheazKqY>
Subject: Re: [v6ops] Turning on IPv6 Routers
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: Fri, 21 Jul 2017 11:24:49 -0000

Fred Baker <fredbaker.ietf@gmail.com> wrote:
    > Note that this is not as simple as it might sound. There are at least
    > three configurations that must be allowed for upstream: bridging the
    > ISP downstream and CPE downstream LANs, Address allocation via DHCP
    > IA_NA, and address allocation via SLAAC, and on the CPE downstream
    > LAN(s), address allocation via DHCP IA_NA and SLAAC. BBF TR-124 gives a
    > flowchart for this or RFC 7084 defines the algorithms. The
    > implementation is going to have to enable all three, see which works,
    > and act accordingly.

As an implementer of a PPPoE aggregator/access-router, I found that I
had to invert 7084 to determine what I had to implement.

It might be worth a document, if only so that ISPs would have something
against which to issue RFPs.  Maybe.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email