Re: [v6ops] Implementation Status of PREF64

Ted Lemon <mellon@fugue.com> Fri, 08 October 2021 22:24 UTC

Return-Path: <mellon@fugue.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 B00873A0B6E for <v6ops@ietfa.amsl.com>; Fri, 8 Oct 2021 15:24:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20210112.gappssmtp.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 Ij4DSQUS8lpg for <v6ops@ietfa.amsl.com>; Fri, 8 Oct 2021 15:23:59 -0700 (PDT)
Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 A751C3A0B69 for <v6ops@ietf.org>; Fri, 8 Oct 2021 15:23:59 -0700 (PDT)
Received: by mail-ot1-x32f.google.com with SMTP id k2-20020a056830168200b0054e523d242aso3845074otr.6 for <v6ops@ietf.org>; Fri, 08 Oct 2021 15:23:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LZyI5BYdauiopibh6OmMTq98tl7f8S6wgoe5s7Vai4I=; b=ykygEqk28YRzJitohLtEONXV2o42ct0hQtmzGFfB+eSSO86f/+t54xx7ciGqjVAsF7 bsoWhhNmrivHXCov7NV7GXJfvnTXUv/DzjBRlVNhKLhUnkll7jjS+4PBurV4eNwpbWnn BV0JeK/BaOIACpvCWushjJ5SmnEHj2mwd6/iaW6juGtlbpjaEr8f599IxW9Pj19R4p5V /Oe4Rc/7ksu3rJUbUMUczLcU3CbagHQ5cmGVUUhantGp9Uw9jrAeNfnslymkhUy/U6E/ lIsXR3Qdd3ByHV+gtug2qkNr238JjYpbIAL3AzH+6w/IkiyEehHSIJUZlLY+ebxJAoMa XkDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LZyI5BYdauiopibh6OmMTq98tl7f8S6wgoe5s7Vai4I=; b=NJMc8J6KM1L/CywT1ZxY6X+Hu9g0vingN3cFWToS+FJNHRWkUdrM5R1jgFwZVgU9Zd 1i9ZttgfZ0UiO9LRXd8k5T/C/dRr313Yg18v5UaYbEJTaTH156i+ci7l2be6d4lgeAb7 gV2qA/y4tRD01+lmLycr+LGZ3XIeeMZbj9I0arlfNShbL2HnlULvM1n2Gb+vDSMDSJKi CgebEAtAL/jBeF4HHWhB159NaWXs5Mv5b6Vxf96/+S/da8IBwuM/sV7J0cckC8DAsE9F q61cYdKIkKOlYvgKfUzoHWvblztc0MUIZLUAHnugluyA7XOJVI/LclvjfDwia81zemo8 VibQ==
X-Gm-Message-State: AOAM532U4x6n/k0XT8m6n7gkv1nUMQCPMJgaJLnmWaK3S1zAztB7QaWv /yV7VADUmZ5Pg6YT0qCy8MgxDh/wHbQh6OfR5b/Jtg==
X-Google-Smtp-Source: ABdhPJwV6c2VAybqdIZDMeOojrDmsRPeBHM3uboFgrQHJN5+HTFlNANGFovSAaVCBZD/+cBy5b/xaKrXe7YNC2wZ9Dg=
X-Received: by 2002:a9d:7091:: with SMTP id l17mr10732768otj.309.1633731837058; Fri, 08 Oct 2021 15:23:57 -0700 (PDT)
MIME-Version: 1.0
References: <DDA36020-90CC-471B-83AD-3D98950F1164@delong.com> <CAKD1Yr0T-7t-UHbsJBMLpTjKhPAV5uUQkux6oby89TVUue7PyA@mail.gmail.com> <CO1PR11MB4881D400EA4681F1505040D2D8AA9@CO1PR11MB4881.namprd11.prod.outlook.com> <CAKD1Yr3TmqFxjKuZ57wS7VuPOf6rJvOwnvnQdFrRLQ=DkZ+CCw@mail.gmail.com> <CO1PR11MB4881F411A4D5BEA7A8479726D8AA9@CO1PR11MB4881.namprd11.prod.outlook.com> <D8AEA194-293B-43E4-BCAE-33CD81FB7D8C@delong.com> <CAKD1Yr2Tug-PFV7wAh0s6-gw8W3LcLG7wC1fD7Lu_hMZQYKdtw@mail.gmail.com> <08D2885E-B824-48E8-9703-DCA98771FA37@delong.com> <CAKD1Yr2EVsY3tYUf56R0Q1+KVrowtqh-HgwXj5vxzy4wd-vkTg@mail.gmail.com> <1A6ED87B-666E-439C-852F-2E5C904C0515@delong.com> <CAKD1Yr23fY2DJDvB-9eVFRsxnBnZQ0kZuZfYUfRUHYW=_D=enA@mail.gmail.com> <CAN-Dau1z0q0R61x7iY+Wg_cFRU0jmqr+fR0y=bSXxj+K-n722w@mail.gmail.com> <CAKD1Yr1T_mXfxJGHOrBfqZfexm6GTrUqnFi57710pTroKQK6uQ@mail.gmail.com> <702CB018-1A02-4B32-B9AA-7C7B31521F12@delong.com> <CAKD1Yr0jZR8Efzr_Y6FeiBvHYS8ATmDupx2ABTXXy-rSA_QjmA@mail.gmail.com> <1adb70a8-db0a-4ea6-f721-c1035343cda3@foobar.org> <DM6PR02MB69249D4F0A8003E77EC9F153C3B19@DM6PR02MB6924.namprd02.prod.outlook.com> <CAN-Dau0q7p-9NWv=9vouX51Z1Yqe_h06WwpnkMjkyj6=A7EcQw@mail.gmail.com> <CEF113D2-1F80-422F-BBD1-1E1951367A2F@delong.com>
In-Reply-To: <CEF113D2-1F80-422F-BBD1-1E1951367A2F@delong.com>
From: Ted Lemon <mellon@fugue.com>
Date: Fri, 08 Oct 2021 18:23:21 -0400
Message-ID: <CAPt1N1=Z6bB3dDDODt09fTrGqTDUnSdZc6E7PDkJeGUKANtOgA@mail.gmail.com>
To: Owen DeLong <owen=40delong.com@dmarc.ietf.org>
Cc: David Farmer <farmer=40umn.edu@dmarc.ietf.org>, v6ops list <v6ops@ietf.org>, Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ce782c05cdded54c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/lkP6bxJ8W24_q-wY_n7-9e0UH0k>
Subject: Re: [v6ops] 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: Fri, 08 Oct 2021 22:24:05 -0000

It amazes me to see a serious discussion here that's motivated by a belief
about what "most enterprises are doing and why" that isn't based on any
cited data about what and why. It would be awfully nice if this discussion
could be set aside until such data is sourced.

I suspect the reason that most enterprises that aren't deploying IPv6
aren't deploying it is because they see cost and no benefit. Fixing the
DHCPv6 problem, if indeed it is a problem, won't change that.

This is not to say that the individual operational issues people have
discussed here aren't real issues or don't matter, but it would be nice if
we could keep it real. If the problem is that it's not working for you,
that's a valid problem. But it's not necessarily the same problem that
other enterprises are struggling with, if indeed they are struggling with
it at all.

On Fri, Oct 8, 2021 at 4:37 PM Owen DeLong <owen=40delong.com@dmarc.ietf.org>
wrote:

>
>
> On Oct 8, 2021, at 9:28 AM, David Farmer <farmer=40umn.edu@dmarc.ietf.org>
> wrote:
>
>
>
> On Thu, Oct 7, 2021 at 8:21 AM STARK, BARBARA H <bs7652@att.com> wrote:
>
>> > > but hosts should not
>> > > be able to set policies on how many IPv6 addresses they accept.
>> >
>> > Sure they can.  There's nothing stopping a dhcpv6 client from refusing
>> > to enable ipv6 on an interface if it gets less than N addresses.
>>
>> Host policy should be dictated by the people in control of the host and
>> not IETF.
>> IETF has no business restricting the rights of device owners and private
>> networks operators to dictate what devices are allowed to do on their
>> network. This sort of prohibition on device owners and private network
>> admins setting host policy would be 100% harmful.
>>
>
> Ok, the IETF shouldn't pick N, I'm ok with that. But, does that mean you
> think it is inappropriate for host implementations to enforce some number
> of IPv6 addresses be available? Or, are you saying that is completely up to
> network operators?
>
>
> If I operate a network, I don’t think that a host should be able to demand
> N addresses from my network (for any value of N).
>
> It can ask. I can give it as many or as few as I’m willing. It can decide
> to use what I offer or not.
>
> I will note a few things;
>
> 1. The IETF hasn't picked a value of  N, but it has, through RFC7934, said
> that N<1.
>
>
> I doubt that. N<1 would be utterly useless… Perhaps N>1?
>
> 2. In effect Android already enforces, N<1, by only supporting the
> self-assigned addressing model of SLAAC.
>
>
> Yes, because Android has a large market share, they are, in effect,
> through their refusal to adopt IA_NA, bullying (or at least attempting to
> bully) network operators that choose to implement IPv6.
>
> This divides the community into three groups…
>
> + Those that are not implementing IPv6 at least in part because of this
> issue
> (probably the vast majority of enterprises at this point)
> + Those that are being subverted by this bullying
> + Those that are implementing IPv6 in a “sorry, android, you can’t play
> until you fix it” mode.
> (by far the least populous group for now)
>
> 3. However, by not supporting a DHCPv6 client, Android doesn't support the
> managed-assignment addressing model of DHCPv6.
>
> In an effort to find a compromise that allows Android to support DHCPv6
> and therefore the managed-assignment addressing model, I'm suggesting it is
> reasonable for DHCPv6 clients to require the availability of more than one
> IPv6 address before it enables it's IPv6 stack, and it sounds like Lorenzo
> is at least open to discuss such a comprise.
>
>
> The client is free to implement whatever minimums to implement its v6
> stack it wants. IETF doesn’t need to weigh in on this, no standardization
> is required.
>
> Android will simply become known as oddly dysfunctional in IPv6 which is
> an apt description for such behavior.
>
> However, it seems that some people are insisting that network operators
> should be able to assign one and only one IPv6 address per client.
> Personally, I think this argument is utterly futile, is creating a
> deadlock, and it is holding back the deployment of IPv6. However, this
> deadlock is not caused only by Android not supporting DHCPv6, but it is
> also caused by those that insist that assigning one and only one address is
> a valid IPv6 deployment strategy, and that network operators should have
> ultimate and unilateral control in this matter.
>
>
> Network operators by and large own the networks they are operating and
> they should have unilateral control over the numbering decisions on those
> networks. To claim that some hardware vendor should be entitled to override
> the operators wishes just because they don’t like the implications is silly.
>
> Do I think that network operators _SHOULD_ allocate more than one address
> per client? Absolutely.
> Do I think that it is IETF or Google’s or Lorenzo’s place to say that they
> MUST? Absolutely not.
> Heck, I’d like to see ISPs required to hand out /48s per site regardless
> of customer type or size.
>
> Nonetheless, the operator pays for and builds the infrastructure, the
> operator deals with registering the address and takes responsibility (at
> least in the enterprise case) for the goings on on the operator’s network.
> As such, yes, the operator gets to absolutely decide what resources any
> given host is allowed on their network.
>
> I'm willing to concede that network operators need to allocate more than
> one IPv6 address per client.. Furthermore, I think it is very important
> that all major operating systems allow for both IPv6 address
> assignment models, self-assigned (SLAAC) and managed-assignment (DHCPv6).
>
>
> I’m willing to concede that they should. I’m also willing to accept
> android shutting down its IPv6 stack if it wants to throw a temper tantrum
> over the resource constraints of the network it’s trying to attach to. I’m
> not willing to take that next step and say that operators should be
> dictated to by IETF, Google, Lorenzo, et. al.
>
> I'm having visions of IETF becoming not unlike the Texas legislature in
>> its desire to dictate "morality".
>>
>
> Yeah, let’s let every android user sue for $10,000 if they can’t get their
> preferred number of addresses… Yay.
>
> Owen
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>