From owen@delong.com Mon Nov 6 13:51:35 2023 Return-Path: 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 2DFC2C18E530 for ; Mon, 6 Nov 2023 13:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 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, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=delong.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDWawfYpUCE7 for ; Mon, 6 Nov 2023 13:51:30 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id BD07EC18772F for ; Mon, 6 Nov 2023 13:51:30 -0800 (PST) Received: from smtpclient.apple (75-10-5-143.lightspeed.sntcca.sbcglobal.net [75.10.5.143]) (authenticated bits=0) by owen.delong.com (8.17.1/8.15.2) with ESMTPSA id 3A6LpMYN106942 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 6 Nov 2023 21:51:22 GMT DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 3A6LpMYN106942 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1699307482; bh=SK6OSkjp9FuKIveH/O+JTMsEuMq7PrOEC7fW4Jsf2cs=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=nqmzGDgQAyHmk0pEEU5uySb/fZUQm2lfIuuPRM0aBszFHg6hqV7g6ePydMfDlSqie LAb1KVnoDbgpHQJRHFYVN/gQiCdggIaXhWhzcOiE2Y8fC0Hz0D+wBBgMkj4Hs5lvum LyQC64UbWPcgUx5ueDK2Cm96UU4Tzys3OkzJg5Gs= From: "Delong.com" Message-Id: <296488E6-9A10-41B7-9C77-8AC03A91B5A7@delong.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_723246D4-E9CB-4915-BB2C-2EAD374A458A" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\)) Date: Mon, 6 Nov 2023 13:51:11 -0800 In-Reply-To: <5666162.ihCYSUqkRZ@asclepius.adm.tul.cz> Cc: Lorenzo Colitti , Xiao Ma , V6 Ops List To: =?utf-8?Q?Martin_Hun=C4=9Bk?= References: <169919966581.36738.5162400304409089286@ietfa.amsl.com> <4598146.F5Vx1aKkY9@asclepius.adm.tul.cz> <5666162.ihCYSUqkRZ@asclepius.adm.tul.cz> X-Mailer: Apple Mail (2.3774.200.91.1.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.4 (owen.delong.com [192.159.10.2]); Mon, 06 Nov 2023 21:51:22 +0000 (UTC) Archived-At: Subject: Re: [v6ops] New Version Notification for draft-ietf-v6ops-dhcp-pd-per-device-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2023 21:51:35 -0000 --Apple-Mail=_723246D4-E9CB-4915-BB2C-2EAD374A458A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 6, 2023, at 11:46, Martin Hun=C4=9Bk = wrote: >=20 > Hi, >=20 > Dne pond=C4=9Bl=C3=AD 6. listopadu 2023 10:00:14 CET, Lorenzo Colitti = napsal(a): >> On Mon, Nov 6, 2023 at 2:41=E2=80=AFAM Martin Hun=C4=9Bk = wrote: >>=20 >>> If you have at least X+32 of IPv6, you can be in the same situation = with >>> IPv6 as you are in IPv4. Now, do we want to be in the same = situation? Why >>> migrate to IPv6, then? >>>=20 >>=20 >> It's not the same situation. As the draft explains, x+32 is 32 times = better >> than IPv4 if we never move beyond 2000::/3. If we move beyond = 2000::/3, >> it's 256 times better than IPv4. Whether any given network has enough = space >> for that is up to the operators and the RIRs. Based on your comments, = it's >> clearly not enough for your network. That's OK - whether a network = uses >> this model is up to the network, and it's pretty clear that there are = some >> networks, like home networks with only a /64 or a /60, that will = never be >> able to run this model due to lack of space. >=20 > I do have /16 of IPv4 and /48 of IPv6. By the formula presented in the = draft I get the exact result: > X =3D 16 > 16 + 32 =3D 48 > So I'm in precisely the same situation as I'm with IPv4. How is it any = better than the address-space constraints of IPv4? I do not necessarily = care who is to blame. I just know what I have, and even if I'm allowed = to expand the address space, I would be forced to renumber. There would = be almost zero gain for clients having /64 compared to /80 (when we do = not allow network extension), so for me personally, having a strict /64 = barrier is just a complication and a poor design choice, especially when = a host is not informing how big a prefix it really needs. Well=E2=80=A6 In IPv4, you have 65,536 unique addresses and can number = (up to) 65,534 unique hosts (assuming a flat network with no subnetting) = and each host gets exactly one address. With this proposal, you can (theoretically) number 65,536 unique hosts = each of which can either provide a downstream subnet to attached hosts = (acting as a router) or unique additional address to = containers/VMs/services/whatever on the actual host (or presumably with = some creative allocation policy and bridging some combination of both). So I wouldn=E2=80=99t call that =E2=80=9Cexactly the same situation=E2=80=9D= . Further, not every host has to ask for or receive a /64, presumably = this is being done through PD on request, so you could have entire = networks that don=E2=80=99t make use of this draft or parts of networks = or=E2=80=A6 There=E2=80=99s a lot more flexibility here than with IPv4 even in the = worst case scenario that you focus on, and the reality is that very few = implementations will actually represent the kinds of absolutism being = discussed here. >> FWIW, I think you said that in order to use this you'd need to assign = a /49 >> to your Wi-Fi network? That doesn't seem unreasonable to me, or to = other >> operators that are part of this discussion. >=20 > It doesn't seem reasonable to me. It is half of my address space, and = I won't be getting more; it is without reserves to expand, and I had to = move several networks to clear it. If a host would have been fine with = /80, I would be just fine with one /64 or /63 (or /60). I could manage = just fine with what I have. It makes even more sense as we do not allow = a network extension. OK, since you don=E2=80=99t allow network extension, and you don=E2=80=99t= want to support SLAAC in your environment, presumably you can implement = outside of the recommendations contained in this draft. AIUI, this is an = informational / best practice draft and not a standards-track document. = As such, I think we should document the case that covers the majority of = use situations and accept that some corner cases (such as yours) may not = fit. >>=20 >> Remember, what we are trying to do here is a compromise: provide to = network >> operators the control and tracking that they like to have via DHCPv6, = while >> ensuring that connected devices can support pretty much any use case, >> including hosts forming unlimited addresses, plugging in routers, and = doing >> a moderate amount of network extension with end-to-end connectivity = and >> without NAT. We think this model has a lot of advantages, but it's >> definitely not the only one. >=20 > If any user is allowed to extend the network, how do I know who is the = end user? Unsupported, not allowed things should be hard to get working. = If someone tries to extend the network (while not allowed to do so), I = want his/her attempt to fail. Then, the broken connectivity is desired. >=20 > Btw: Do you have any data about how big a share of a company allows = the "bring your own router" policy in their corporate network? Network = extension in corporate networks is not a common use case, in my opinion. Network extension within policy is not a common use case. As someone whose job has regularly included tracking such extensions = down and extinguishing them due to policy !=3D user intent, I can = absolutely guarantee you that it is a much more common use case than = you=E2=80=99d like to believe. I=E2=80=99ll also guarantee you that = users will go to impressive and bizarre lengths to do so. In the IPv4 = world, the common solution is just more layers of NAT which (IMHO) is = even worse because now the extension is virtually transparent, nearly = undetectable, and a major pain to identify and resolve. At least if the host is asking for a /64 and extending the network, you = have some visibility into what is happening, even if the exact topology = isn=E2=80=99t 100% transparent. Bottom line, today, what you don=E2=80=99t want to allow is already = super easy in IPv4. >> I agree with Gert. You can have /80s all you want, but you are not = getting >>> /64s from me. If your implementation requires it, then it is NAT66 = for you, >>> ND proxy, or IPv4 only. You choose. >>>=20 >>=20 >> I hate to say it, but... network operators saying, "my network, my = rules" >> and insisting that devices will only have the amount of address space = that >> they think they need is precisely why host implementers don't trust >> networks to do the right thing. >=20 > The implementers know less about the network the device is connected = to than the admins running it. Quite frankly, you would not be able to = know local restrictions, nor would you care. >=20 > Yes, we can make this mutual distrust basis to reconsider BYOD = policies. This is a religious issue that isn=E2=80=99t (and probably shouldn=E2=80=99= t) going to get resolved in the IETF, IMHO. Each network operator and the hosts administrators using said network = ends up having to find some balance they can both accept on a = case-by-case basis. In environments where there are professionals on both sides of the = equation able to work as a team, this can go fairly smoothly. In = environments where host administration is the Wild West of software = developers doing whatever they think they need without regard to network = or corporate policy, this can be a much bigger adventure. In = environments where the networking team went to the BOFH school of = network management, this can also be a much bigger adventure. I=E2=80=99ve seen examples of all three of these scenarios. The obvious = worst case is Wild West developers + a BOFH trained network team (and = I=E2=80=99ve seen that too). >> This is why we need a fixed boundary - otherwise we end up with a = race to >> the bottom that ends at /128. At the moment, the only possible fixed >> boundary is /64, because once the device gets a /64, it can do = whatever it >> wants, and extend the network all it wants, using SLAAC. If we make = SLAAC >> run on longer prefixes, then maybe we'll all agree on one size. But = who >> knows if that will work. Just like you say, "you can have all the = /80s you >> want, but you're not getting /64s", some other operators saying, "you = can >> have all the /128s you want, but you're not getting /80s". One thing = at a >> time. If we make this model work with /64s, maybe it's possible to = imagine >> changing SLAAC. >>=20 > Do you really think that? Yes, there will be some networks that will = use IPv4 principles and try to conserve IP space so much that they try = to give too little to clients. However, many more are adhering to = recommendations made by IETF or RIR. At ISP, I give /56 to residential = clients, /48 to companies (or upon request). I could give just /64 or = /60, but I know what I would like to have at home and how many I can = assign to maintain a reasonable addressing plan. It is up to me as a = Network administrator to make the plan and configure my routers = accordingly. Last I looked, the largest US Cable MSO is giving out /64 to residential = end users unless they request up to a /60. The won=E2=80=99t give = anything shorter than /60 to a residential customer. I believe their business customers can get up to a /56. There=E2=80=99s a guy running around most of the WISP conferences in the = US that unfortunately has the ear of lots of WISPs and preaches /60 for = customer end sites.=20 As such, I think your statement about =E2=80=9Cmost=E2=80=9D might hold = water, but in terms of most customers impacted, no, it does not. > I'm not really in the camp of let's change an SLAAC prefix size as we = would not see practical results in years to come. However, if it = provides me with additional tools to manage my networks, then why not? I could care less about changing the SLAAC prefix size, but I wouldn=E2=80= =99t oppose a draft requiring support for greater prefix size = flexibility in SLAAC. My concern is that if we manage to make SLAAC with = /80 (for example) default working configuration across a wide variety of = residential gateways, you=E2=80=99ll see MSOs treat that as an excuse to = start handing out /76 instead of /60. > This draft is a bit different. If every device required a /64 and it = would like to extend the network, I would be pushed around, and I hate = that. Clients would push me to give them /64, SCO would push me on = network security front, and RIPE policy and upstream addressing plan are = constraining me with address space. Having an OS vendor pushing me with = the substantial number of devices is the thing I need the least. Actually, RIPE policy isn=E2=80=99t constraining you here. RIPE policy = would allow you to request additional space. RIPE already defaults to /29 and virtually any half-way believable = justification for a shorter prefix is acceptable under their policy. = Similarly, ARIN policy provides a great deal of flexibility here with = pretty generous nibble-boundary round-ups. I believe the most = restrictive IPv6 policy remains AFRINIC and even it provides relatively = easy ways to get enough address space to accommodate this draft. Owen --Apple-Mail=_723246D4-E9CB-4915-BB2C-2EAD374A458A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Nov 6, 2023, at 11:46, Martin Hun=C4=9Bk = <martin.hunek@tul.cz> wrote:

Hi,

Dne pond=C4=9Bl=C3=AD 6. = listopadu 2023 10:00:14 CET, Lorenzo Colitti napsal(a):
On Mon, Nov 6, 2023 at 2:41=E2=80=AFAM Martin = Hun=C4=9Bk <martin.hunek@tul.cz> wrote:

If you have at least X+32 of IPv6, you can be in the same = situation with
IPv6 as you are in IPv4. Now, do we want to be in the = same situation? Why
migrate to IPv6, = then?


It's not the same situation. As the draft = explains, x+32 is 32 times better
than IPv4 if we never move beyond = 2000::/3. If we move beyond 2000::/3,
it's 256 times better than = IPv4. Whether any given network has enough space
for that is up to = the operators and the RIRs. Based on your comments, it's
clearly not = enough for your network. That's OK - whether a network uses
this = model is up to the network, and it's pretty clear that there are = some
networks, like home networks with only a /64 or a /60, that will = never be
able to run this model due to lack of = space.

I do = have /16 of IPv4 and /48 of IPv6. By the formula presented in the draft = I get the exact result:
X =3D = 16
16 + 32 =3D 48
So I'm in precisely the = same situation as I'm with IPv4. How is it any better than the = address-space constraints of IPv4? I do not necessarily care who is to = blame. I just know what I have, and even if I'm allowed to expand the = address space, I would be forced to renumber. There would be almost zero = gain for clients having /64 compared to /80 (when we do not allow = network extension), so for me personally, having a strict /64 barrier is = just a complication and a poor design choice, especially when a host is = not informing how big a prefix it really needs.

Well=E2=80=A6 In IPv4, you have = 65,536 unique addresses and can number (up to) 65,534 unique hosts = (assuming a flat network with no subnetting) and each host gets exactly = one address.

With this proposal, you can = (theoretically) number 65,536 unique hosts each of which can either = provide a downstream subnet to attached hosts (acting as a router) or = unique additional address to containers/VMs/services/whatever on the = actual host (or presumably with some creative allocation policy and = bridging some combination of both).

So I = wouldn=E2=80=99t call that =E2=80=9Cexactly the same situation=E2=80=9D. = Further, not every host has to ask for or receive a /64, presumably this = is being done through PD on request, so you could have entire networks = that don=E2=80=99t make use of this draft or parts of networks = or=E2=80=A6

There=E2=80=99s a lot more = flexibility here than with IPv4 even in the worst case scenario that you = focus on, and the reality is that very few implementations will actually = represent the kinds of absolutism being discussed = here.

FWIW, I think you said that in order to use this you'd need to = assign a /49
to your Wi-Fi network? That doesn't seem unreasonable to = me, or to other
operators that are part of this = discussion.

It = doesn't seem reasonable to me. It is half of my address space, and I = won't be getting more; it is without reserves to expand, and I had to = move several networks to clear it. If a host would have been fine with = /80, I would be just fine with one /64 or /63 (or /60). I could manage = just fine with what I have. It makes even more sense as we do not allow = a network extension.

OK, since you = don=E2=80=99t allow network extension, and you don=E2=80=99t want to = support SLAAC in your environment, presumably you can implement outside = of the recommendations contained in this draft. AIUI, this is an = informational / best practice draft and not a standards-track document. = As such, I think we should document the case that covers the majority of = use situations and accept that some corner cases (such as yours) may not = fit.


Remember, what we are trying to do here is a compromise: = provide to network
operators the control and tracking that they like = to have via DHCPv6, while
ensuring that connected devices can support = pretty much any use case,
including hosts forming unlimited = addresses, plugging in routers, and doing
a moderate amount of = network extension with end-to-end connectivity and
without NAT. We = think this model has a lot of advantages, but it's
definitely not the = only one.

If any = user is allowed to extend the network, how do I know who is the end = user? Unsupported, not allowed things should be hard to get working. If = someone tries to extend the network (while not allowed to do so), I want = his/her attempt to fail. Then, the broken connectivity is = desired.

Btw: Do you have any = data about how big a share of a company allows the "bring your own = router" policy in their corporate network? Network extension in = corporate networks is not a common use case, in my opinion.

Network extension within policy = is not a common use case.

As someone whose job = has regularly included tracking such extensions down and extinguishing = them due to policy !=3D user intent, I can absolutely guarantee you that = it is a much more common use case than you=E2=80=99d like to believe. = I=E2=80=99ll also guarantee you that users will go to impressive and = bizarre lengths to do so.  In the IPv4 world, the common solution = is just more layers of NAT which (IMHO) is even worse because now the = extension is virtually transparent, nearly undetectable, and a major = pain to identify and resolve.

At least if the = host is asking for a /64 and extending the network, you have some = visibility into what is happening, even if the exact topology isn=E2=80=99= t 100% transparent.

Bottom line, today, what = you don=E2=80=99t want to allow is already super easy in = IPv4.

I agree with Gert. You can have /80s all you want, but you are = not getting
/64s from me. If your = implementation requires it, then it is NAT66 for you,
ND proxy, or = IPv4 only. You choose.


I hate to say it, but... = network operators saying, "my network, my rules"
and insisting that = devices will only have the amount of address space that
they think = they need is precisely why host implementers don't trust
networks to = do the right thing.

The = implementers know less about the network the device is connected to than = the admins running it. Quite frankly, you would not be able to know = local restrictions, nor would you care.

Yes, we = can make this mutual distrust basis to reconsider BYOD = policies.

This is a religious issue that = isn=E2=80=99t (and probably shouldn=E2=80=99t) going to get resolved in = the IETF, IMHO.

Each network operator and the = hosts administrators using said network ends up having to find some = balance they can both accept on a case-by-case = basis.

In environments where there are = professionals on both sides of the equation able to work as a team, this = can go fairly smoothly. In environments where host administration is the = Wild West of software developers doing whatever they think they need = without regard to network or corporate policy, this can be a much bigger = adventure. In environments where the networking team went to the BOFH = school of network management, this can also be a much bigger = adventure.

I=E2=80=99ve seen examples of all = three of these scenarios. The obvious worst case is Wild West developers = + a BOFH trained network team (and I=E2=80=99ve seen that = too).

This is why we need a fixed boundary - otherwise we end up with a = race to
the bottom that ends at /128. At the moment, the only = possible fixed
boundary is /64, because once the device gets a /64, = it can do whatever it
wants, and extend the network all it wants, = using SLAAC. If we make SLAAC
run on longer prefixes, then maybe = we'll all agree on one size. But who
knows if that will work. Just = like you say, "you can have all the /80s you
want, but you're not = getting /64s", some other operators saying, "you can
have all the = /128s you want, but you're not getting /80s". One thing at a
time. If = we make this model work with /64s, maybe it's possible to = imagine
changing SLAAC.

Do you = really think that? Yes, there will be some networks that will use IPv4 = principles and try to conserve IP space so much that they try to give = too little to clients. However, many more are adhering to = recommendations made by IETF or RIR. At ISP, I give /56 to residential = clients, /48 to companies (or upon request). I could give just /64 or = /60, but I know what I would like to have at home and how many I can = assign to maintain a reasonable addressing plan. It is up to me as a = Network administrator to make the plan and configure my routers = accordingly.

Last I looked, the largest US = Cable MSO is giving out /64 to residential end users unless they request = up to a /60. The won=E2=80=99t give anything shorter than /60 to a = residential customer.

I believe their business = customers can get up to a /56.

There=E2=80=99s = a guy running around most of the WISP conferences in the US that = unfortunately has the ear of lots of WISPs and preaches /60 for customer = end sites. 

As such, I think your = statement about =E2=80=9Cmost=E2=80=9D might hold water, but in terms of = most customers impacted, no, it does not.

I'm not = really in the camp of let's change an SLAAC prefix size as we would not = see practical results in years to come. However, if it provides me with = additional tools to manage my networks, then why not?

I could care less about = changing the SLAAC prefix size, but I wouldn=E2=80=99t oppose a draft = requiring support for greater prefix size flexibility in SLAAC. My = concern is that if we manage to make SLAAC with /80 (for example) = default working configuration across a wide variety of residential = gateways, you=E2=80=99ll see MSOs treat that as an excuse to start = handing out /76 instead of /60.

This = draft is a bit different. If every device required a /64 and it would = like to extend the network, I would be pushed around, and I hate that. = Clients would push me to give them /64, SCO would push me on network = security front, and RIPE policy and upstream addressing plan are = constraining me with address space. Having an OS vendor pushing me with = the substantial number of devices is the thing I need the = least.

Actually, RIPE policy isn=E2=80=99= t constraining you here. RIPE policy would allow you to request = additional space.

RIPE already defaults to /29 = and virtually any half-way believable justification for a shorter prefix = is acceptable under their policy. Similarly, ARIN policy provides a = great deal of flexibility here with pretty generous nibble-boundary = round-ups. I believe the most restrictive IPv6 policy remains AFRINIC = and even it provides relatively easy ways to get enough address space to = accommodate this = draft.

Owen

= --Apple-Mail=_723246D4-E9CB-4915-BB2C-2EAD374A458A--