[v6ops] Campus roaming [was Re: Implementation Status of PREF64]

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 14 October 2021 20:30 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D6C8D3A0CAD for <v6ops@ietfa.amsl.com>; Thu, 14 Oct 2021 13:30:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id AU4Fy4sPagDh for <v6ops@ietfa.amsl.com>; Thu, 14 Oct 2021 13:30:02 -0700 (PDT)
Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 31E293A0CBD for <v6ops@ietf.org>; Thu, 14 Oct 2021 13:30:02 -0700 (PDT)
Received: by mail-pg1-x532.google.com with SMTP id m21so6543408pgu.13 for <v6ops@ietf.org>; Thu, 14 Oct 2021 13:30:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=1EVG9WDSZLmr/izRh4vLmM5SwVFD5H4Tp1CUxV0DWeg=; b=YVcHjjmxhQRgex2In/NdLTUUazWBAE8dTEVFXuR0Rq0itBeIyqerfH5An1/807UB75 EtxA0rj0okus3l4NrXqA6vUOY5KaXQCNsinSK/0d6lGaicPzZ+FLhCO17iACp58TPJjN H/9M4Y1QL8NVHEhbvlMBN5954ju1QikssYrpvbYGljnquB9fxsxwa/xbTLmUD7luewUt raBmHtgWyXxAy+1dWufbu3tKQ/atdn5huEnMZedsnqIm/6N1ZTlIKN7QqBsFhJAIiw/P EIQQoUvCBjiNXHDgiRLkw7LkoSCE06rHgmdSTeNKPgxe18K0yiXrRIxVhsvMSuxFYsBr AB0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=1EVG9WDSZLmr/izRh4vLmM5SwVFD5H4Tp1CUxV0DWeg=; b=A3Yhpj2ZZ6Owt3i4CV4rEnfcYULzqkaX5dBVaqX/YSMiUTAE9hxa1A+4of5qX7T9u5 NVBrGQ4bk8ZTalfPCL/dQpkVIJJ3k2wNO7eY3A8uzvuNKDdG7/LjrQkoi6fNy3NsN+59 eg53Drl7Blk7URn+bHS5iZ2/bx4c6p2Reoxad8c7B59FEeiDi83nHnJk68k7hXYmz42J sp4+Er59hKnbwe4PWQdHF2R8sb3o6pQbCmAFNRV8Ip0QlYNllBY6M62cliYSDmCFtjXk 2zj6flo2HYY0iv7I3ThF5w9ZgiRdxZkYPVnwHDlz3H4Qv6QBBjXH9g341eYbBPoOyxOg FbDg==
X-Gm-Message-State: AOAM53074QVhkzeb1weySrSHEHHP1grOw76VX/M5Ln6USJ2w6JsluHT8 uDgRItgi7CqedfTSozDl8+FD42dESHY=
X-Google-Smtp-Source: ABdhPJzznBOVxunCHdFkytGf9hhDbog1Yqu8h19Xzczu1l9AEfq6XJsTiJvbFH0IB43KLTS3A/v+Og==
X-Received: by 2002:a05:6a00:1346:b0:44d:242a:8151 with SMTP id k6-20020a056a00134600b0044d242a8151mr7450002pfu.62.1634243401224; Thu, 14 Oct 2021 13:30:01 -0700 (PDT)
Received: from ?IPv6:2406:e003:102d:e801:db7:d041:a2d:ce65? ([2406:e003:102d:e801:db7:d041:a2d:ce65]) by smtp.gmail.com with ESMTPSA id ng5sm2827946pjb.51.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 14 Oct 2021 13:30:00 -0700 (PDT)
To: "Pascal Thubert (pthubert)" <pthubert=40cisco.com@dmarc.ietf.org>, Owen DeLong <owen=40delong.com@dmarc.ietf.org>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
References: <CAKD1Yr10OKMJ1y8bs5xpt6jS8ZWsqs66oFCXmp-QLySS5Yn4hg@mail.gmail.com> <5DF8D1AE-4B54-429F-962A-488F2AA1F895@delong.com> <CAPt1N1ma45GKqXcvjHUGCYFKVbEGp3OuT013pZhrnOkFFLMiQA@mail.gmail.com> <CAKD1Yr2Pe+=tNkA7Ou9KeMkgFhcdSb8WxgVn1w9MauusMEhRcw@mail.gmail.com> <CO1PR11MB4881076DFF8A145C8CD818B8D8B69@CO1PR11MB4881.namprd11.prod.outlook.com> <A188D974-3CEB-497F-93EA-B66C77D2CA90@delong.com> <YWW1ghmjueHmfCEb@Space.Net> <m1maKp6-0000I3C@stereo.hq.phicoh.net> <YWW8FPkRuxCBFp3o@Space.Net> <D0510DEB-04FF-4864-9363-6FC40C686C22@delong.com> <YWcQKwK3lAKpl7y1@Space.Net> <DFD526B0-7CA3-4445-910F-425142C0AEDA@delong.com> <802A4F47-5DB0-4986-894D-2B20BA09FF24@cisco.com> <36CB5B2A-2469-4E51-9536-D16B66BE3B6E@delong.com> <778CB8A4-7F82-4792-A347-27C6C5A70624@cisco.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <e9e0804e-f53c-8975-dff7-7c8e3f5203eb@gmail.com>
Date: Fri, 15 Oct 2021 09:29:55 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <778CB8A4-7F82-4792-A347-27C6C5A70624@cisco.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/jaev8j04qvj-rVXawMSK02n2q9g>
Subject: [v6ops] Campus roaming [was Re: Implementation Status of PREF64]
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 14 Oct 2021 20:30:08 -0000

I hadn't realised that this thread was now about something entirely different. If one doesn't change the Subject when the subject changes, one cannot be be surprised if people ignore the thread...

On 14-Oct-21 19:55, Pascal Thubert (pthubert) wrote:

> Real world exemple: 
> Say I have a large campus, with WiFi coverage throughout. Say I want to 
move around with no renumbering. Say that when I print I want the printer 
to be the one in my room wherever I am in the campus.
> The traditional IPv4 approach is the get an address from the subnet that is served by the AP that you connected to when you entered the campus and tunnel there when you move beyond the small area covered by the subnet. Meaning that your broadcast domain remains that small area and your prints will always get there.

Actually, no. What large campuses tend to do today is have a centralised print queue and a feature whereby the user releases their print jobs *at the printer itself*. Fiddling around with a mechanism that relies on the printer's IP address is not the future.
> With IPv6 a subnet could easily span the campus, but the broadcast domain could not. Ideally the node would see:
> - a broadcast domain with mDNS devices such as the printer down the corridor. This means limited to one open space or a few smaller rooms

I think DNS-SD will do better than that. mDNS is not the future.
> - an IP link to the routers that serve the broadcast domain. The box that we call an AP could easily serve as router and/or ND routing proxy (RFC 8929) within the subnet (call it a L3 AP just like your switch is probably an L3 switch).

How does that work with on-link determination? 

> - An IP subnet that has enough capacity to serve the whole campus.
> We could easily be providing all this to our customers but we’re not. We prefer sterile discussions at 6MAN or NANOG and the consequence 
of our inaction is that they keep deploying  IPv6 as if it was IPv4 with little to no evolution/ benefit. And we complain for the lack of adoption!
> Please, peace: we have 20 years of experience that a discussion for the 
sake of discussing does not get us anywhere. Could we for once work on an 
acceptable trade off?
> Your point: our common customers want one state per device because state is expensive. They do not want uncontrolled address allocation and silent nodes that come with it. They have that with IPv4 do not want to loose 
that going v6. I share that view and observe the same thing.

There's a tussle here between the desire for privacy and the desire for management control. While enterprise network managers might not want uncontrolled address allocation, their users might want it. The IETF has to respect that tussle and make its resolution a deployment issue, not a standards issue. In other words the trade off doesn't happen here.

> Also: They do not want broadcast storms that clog their bandwidth, waste energy and spectrum. They want to scale to a campus or a factory without renumbering.  They want simple (flat) networks as opposed to the tunnels above. They want service for the end users, e.g., the nearest printer.

If you fix the printing (and other app layer) problems at the app layer, as noted
above, and use DNS-SD rather than mDNS to find services, who cares any more which subnet you are on?


> Looking for a consensus:
> You want to assign/128 to the host and defend the case of the use of DHCP in the managed subnet.
> Lorenzo does not want /128 to the host but agrees with DHCP PD.
> Gert wants to avoid the waste of address space just because we can. 
> A prefix to the host gives Lorenzo the addresses he needs for his devices.  It gives your customers the single state per logical node that they want. It allows to separate what netops manage (down to /64 and direct assignment within) and devops (whatever they do with the longer prefix they 
get for their node). It does not impose any size for what’s assigned, could be a different thing for each host. It means routing inside the subnet which removes the dreadful broadcast domain.
> I see an opportunity for consensus. Can we work that out together and bring a real IPv6 value?
> Pascal