Re: a draft about on-link and submit prefixes

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 14 March 2017 22:55 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64947131614 for <ipv6@ietfa.amsl.com>; Tue, 14 Mar 2017 15:55:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level:
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 5ali9fwdwgZW for <ipv6@ietfa.amsl.com>; Tue, 14 Mar 2017 15:55:01 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53EC8129B4C for <ipv6@ietf.org>; Tue, 14 Mar 2017 15:55:01 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 34A22205AB; Tue, 14 Mar 2017 19:18:03 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 21B0C636E0; Tue, 14 Mar 2017 18:54:59 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: IPv6 IPv6 List <ipv6@ietf.org>, Lorenzo Colitti <lorenzo@google.com>
cc: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Subject: Re: a draft about on-link and submit prefixes
In-Reply-To: <CAKD1Yr3ncJkNwZgpWpr049K497iLAQ3dCzJ6dCHM1VsrC8UHog@mail.gmail.com>
References: <CAJE_bqdd9OXOi+SZ8_OfGWXxEoKSfoR6=Lp3-_=vEaWbjx4udw@mail.gmail.com> <CAKD1Yr3ncJkNwZgpWpr049K497iLAQ3dCzJ6dCHM1VsrC8UHog@mail.gmail.com>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Tue, 14 Mar 2017 18:54:59 -0400
Message-ID: <20710.1489532099@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/01Dtzh8DgpGqRmCMniHiiu7mab8>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Mar 2017 22:55:02 -0000

Lorenzo Colitti <lorenzo@google.com> wrote:
    > * IPv6 addresses don't specify any on-link information

    > * For most (but not all) unicast addresses, subnet prefixes are 64
    > bits per RFC 4291.
    > * A given subnet prefix can be spread across multiple links, and a
    > given link can support multiple subnet prefixes.

Is it reasonable for some routers to RA for a PIO as on-link on some
interfaces/ports, and not on others?   I think that this doesn't work unless
you mix in some kind of proxy-ND.

My goal in asking this is to reduce some of the pushback from the reasonable
proposal (in other places, such as homenet) that home wifi not be bridged to
wired, and that different frequencies should have their own prefixes.

The alternative is that all interfaces get not-on-link, and we manage /128
routes, which seems slightly dumb to do on the wired side.

    > A corollary to the above is that subnet prefixes don't specify any
    > on-link information. The fact that the subnet prefix is "almost
    > always" 64 bits long doesn't mean that the on-link prefix cannot be
    > /48, /89 or /120. The fact that the on-link prefix is /120 doesn't
    > mean that nodes on that link have to have addresses in that /120.

Can we do something useful with this?
It seems to me that with DHCPv6 doing assignment, that we could.

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