From prvs=1675b34581=jordi.palet@consulintel.es Tue Nov 7 01:34:13 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 9A73DC17C536 for ; Tue, 7 Nov 2023 01:34:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.003 X-Spam-Level: X-Spam-Status: No, score=-7.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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=consulintel.es 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 WCs5n_ky3jFg for ; Tue, 7 Nov 2023 01:34:09 -0800 (PST) Received: from mail.consulintel.com (mail.consulintel.com [IPv6:2001:470:1f1d:275::250]) by ietfa.amsl.com (Postfix) with ESMTP id BD2B3C1C02A9 for ; Tue, 7 Nov 2023 01:32:59 -0800 (PST) X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.com, Tue, 07 Nov 2023 10:32:57 +0100 Received: from mail.consulintel.es ([2001:470:1f09:495::5]) by mail.consulintel.com ([2001:470:1f1d:275::250]) (MDaemon PRO v16.5.2) with ESMTP id md50001135380.msg for ; Tue, 07 Nov 2023 10:32:56 +0100 X-Spam-Processed: mail.consulintel.com, Tue, 07 Nov 2023 10:32:56 +0100 (not processed: spam filter heuristic analysis disabled) X-MDRemoteIP: 2001:470:1f09:495::5 X-MDHelo: mail.consulintel.es X-MDArrival-Date: Tue, 07 Nov 2023 10:32:56 +0100 X-Return-Path: prvs=1675b34581=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1699349527; x=1699954327; i=jordi.palet@consulintel.es; q=dns/txt; h=From:Content-Type: Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id; bh=VGvzE7g1y/96BVPrPvfNqXJ7taQNGvRdWNXs9igb1Og=; b=OSQX2llUTHPMn uMzLyRFrDGfFMeiZXCxWyA4yQnDU/d57scMJeK1hr2dgLtDO01MoT5KBqVM17C2Z cch2t9tXCRs0V6zV7Q7yWI36A9PW4fjV5NmpQol7n9/uEMKJME65hYvhL6/j9Ept BnWXDLHX5iphExBzV9DOPAPPPBU6q4= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 07 Nov 2023 10:32:07 +0100 X-Spam-Processed: mail.consulintel.es, Tue, 07 Nov 2023 10:32:01 +0100 Received: from smtpclient.apple by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50001290578.msg for ; Tue, 07 Nov 2023 10:32:01 +0100 From: "jordi.palet@consulintel.es" Content-Type: multipart/alternative; boundary="Apple-Mail=_3AEE246E-836E-4A35-AECC-0DDFD14E4AA4" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\)) Date: Tue, 7 Nov 2023 10:31:45 +0100 References: <169919966581.36738.5162400304409089286@ietfa.amsl.com> <4598146.F5Vx1aKkY9@asclepius.adm.tul.cz> <5666162.ihCYSUqkRZ@asclepius.adm.tul.cz> <296488E6-9A10-41B7-9C77-8AC03A91B5A7@delong.com> To: V6 Ops List In-Reply-To: <296488E6-9A10-41B7-9C77-8AC03A91B5A7@delong.com> Message-Id: X-Mailer: Apple Mail (2.3774.200.91.1.1) 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: Tue, 07 Nov 2023 09:34:13 -0000 --Apple-Mail=_3AEE246E-836E-4A35-AECC-0DDFD14E4AA4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Since the last policy changes that I proposed in AFRINIC, I don=E2=80=99t t= hink we can say they are more restrictive than in the other regions. Basica= lly, from a practical point of view, all the regions look almost the same n= ow. Regards, Jordi @jordipalet > El 6 nov 2023, a las 22:51, Delong.com escribi=C3=B3: >=20 >=20 >=20 >> 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 na= psal(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 wi= th >>>> 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 be= tter >>> 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 s= pace >>> for that is up to the operators and the RIRs. Based on your comments, i= t'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 s= ome >>> 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 d= raft 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 b= etter 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 expan= d the address space, I would be forced to renumber. There would be almost z= ero gain for clients having /64 compared to /80 (when we do not allow netwo= rk 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 inform= ing how big a prefix it really needs. >=20 > Well=E2=80=A6 In IPv4, you have 65,536 unique addresses and can number (u= p to) 65,534 unique hosts (assuming a flat network with no subnetting) and = each host gets exactly one address. >=20 > With this proposal, you can (theoretically) number 65,536 unique hosts ea= ch of which can either provide a downstream subnet to attached hosts (actin= g as a router) or unique additional address to containers/VMs/services/what= ever on the actual host (or presumably with some creative allocation policy= and bridging some combination of both). >=20 > 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 th= is is being done through PD on request, so you could have entire networks t= hat don=E2=80=99t make use of this draft or parts of networks or=E2=80=A6 >=20 > There=E2=80=99s a lot more flexibility here than with IPv4 even in the wo= rst case scenario that you focus on, and the reality is that very few imple= mentations will actually represent the kinds of absolutism being discussed = here. >=20 >>> 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 othe= r >>> 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 wo= uld be just fine with one /64 or /63 (or /60). I could manage just fine wit= h what I have. It makes even more sense as we do not allow a network extens= ion. >=20 > OK, since you don=E2=80=99t allow network extension, and you don=E2=80=99= t want to support SLAAC in your environment, presumably you can implement o= utside of the recommendations contained in this draft. AIUI, this is an inf= ormational / best practice draft and not a standards-track document. As suc= h, I think we should document the case that covers the majority of use situ= ations and accept that some corner cases (such as yours) may not fit. >=20 >>>=20 >>> Remember, what we are trying to do here is a compromise: provide to net= work >>> operators the control and tracking that they like to have via DHCPv6, w= hile >>> ensuring that connected devices can support pretty much any use case, >>> including hosts forming unlimited addresses, plugging in routers, and d= oing >>> 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 e= nd 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 hi= s/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 extensio= n in corporate networks is not a common use case, in my opinion. >=20 > Network extension within policy is not a common use case. >=20 > As someone whose job has regularly included tracking such extensions down= and extinguishing them due to policy !=3D user intent, I can absolutely gu= arantee 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 impressiv= e 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 extensio= n is virtually transparent, nearly undetectable, and a major pain to identi= fy and resolve. >=20 > At least if the host is asking for a /64 and extending the network, you h= ave some visibility into what is happening, even if the exact topology isn= =E2=80=99t 100% transparent. >=20 > Bottom line, today, what you don=E2=80=99t want to allow is already super= easy in IPv4. >=20 >>> I agree with Gert. You can have /80s all you want, but you are not gett= ing >>>> /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 rule= s" >>> and insisting that devices will only have the amount of address space t= hat >>> 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 lo= cal restrictions, nor would you care. >>=20 >> Yes, we can make this mutual distrust basis to reconsider BYOD policies. >=20 > This is a religious issue that isn=E2=80=99t (and probably shouldn=E2=80= =99t) going to get resolved in the IETF, IMHO. >=20 > Each network operator and the hosts administrators using said network end= s up having to find some balance they can both accept on a case-by-case bas= is. >=20 > In environments where there are professionals on both sides of the equati= on able to work as a team, this can go fairly smoothly. In environments whe= re host administration is the Wild West of software developers doing whatev= er 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 bigg= er adventure. >=20 > I=E2=80=99ve seen examples of all three of these scenarios. The obvious w= orst case is Wild West developers + a BOFH trained network team (and I=E2= =80=99ve seen that too). >=20 >>> 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 SLA= AC >>> 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 c= an >>> 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 imag= ine >>> 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 comp= anies (or upon request). I could give just /64 or /60, but I know what I wo= uld 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 pla= n and configure my routers accordingly. >=20 > 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. >=20 > I believe their business customers can get up to a /56. >=20 > 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 cus= tomer end sites.=20 >=20 > As such, I think your statement about =E2=80=9Cmost=E2=80=9D might hold w= ater, but in terms of most customers impacted, no, it does not. >=20 >> I'm not really in the camp of let's change an SLAAC prefix size as we wo= uld not see practical results in years to come. However, if it provides me = with additional tools to manage my networks, then why not? >=20 > 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 flexibilit= y in SLAAC. My concern is that if we manage to make SLAAC with /80 (for exa= mple) default working configuration across a wide variety of residential ga= teways, you=E2=80=99ll see MSOs treat that as an excuse to start handing ou= t /76 instead of /60. >=20 >> This draft is a bit different. If every device required a /64 and it wou= ld like to extend the network, I would be pushed around, and I hate that. C= lients would push me to give them /64, SCO would push me on network securit= y front, and RIPE policy and upstream addressing plan are constraining me w= ith address space. Having an OS vendor pushing me with the substantial numb= er of devices is the thing I need the least. >=20 > Actually, RIPE policy isn=E2=80=99t constraining you here. RIPE policy wo= uld allow you to request additional space. >=20 > RIPE already defaults to /29 and virtually any half-way believable justif= ication for a shorter prefix is acceptable under their policy. Similarly, A= RIN policy provides a great deal of flexibility here with pretty generous n= ibble-boundary round-ups. I believe the most restrictive IPv6 policy remain= s AFRINIC and even it provides relatively easy ways to get enough address s= pace to accommodate this draft. >=20 > Owen >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --Apple-Mail=_3AEE246E-836E-4A35-AECC-0DDFD14E4AA4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Since the last policy changes tha= t I proposed in AFRINIC, I don=E2=80=99t think we can say they are more res= trictive than in the other regions. Basically, from a practical point of vi= ew, all the regions look almost the same now.

Regards,
Jordi

@jordipalet


El 6 nov 2023, a las 22:51, Delong.= com <owen=3D40delong.com@dmarc.ietf.org> escribi=C3=B3:



On Nov 6, = 2023, at 11:46, Martin Hun=C4=9Bk <martin.hunek@tul.cz> wrote:
<= br class=3D"Apple-interchange-newline">
Hi,<= br style=3D"caret-color: rgb(0, 0, 0); font-family: LucidaGrande; font-size= : 18px; font-style: normal; font-variant-caps: normal; font-weight: 400; le= tter-spacing: normal; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0p= x; text-decoration: none;">
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&g= t; wrote:

If you have at least X+32 of IPv= 6, you can be in the same situation with
IPv6 as you are in IPv4. Now, d= o 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 mov= e beyond 2000::/3,
it's 256 times better than IPv4. Whether any given ne= twork has enough space
for that is up to the operators and the RIRs. Bas= ed 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 pret= ty clear that there are some
networks, like home networks with only a /6= 4 or a /60, that will never be
able to run this model due to lack of spa= ce.

I do have /16 of IPv4 and /48 of IPv6. By the formula presented i= n the draft I get the exact result:
X =3D 16<= /span>
16 + 32 =3D 48
= So I'm in precisely the same situation as I'm with IPv4. How is it any bett= er than the address-space constraints of IPv4? I do not necessarily care wh= o is to blame. I just know what I have, and even if I'm allowed to expand t= he 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 com= plication 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 a= ddresses and can number (up to) 65,534 unique hosts (assuming a flat networ= k with no subnetting) and each host gets exactly one address.
With this proposal, you can (theoretically) number 65,536 uniqu= e hosts each of which can either provide a downstream subnet to attached ho= sts (acting as a router) or unique additional address to containers/VMs/ser= vices/whatever on the actual host (or presumably with some creative allocat= ion 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 th= is 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 b= eing discussed here.

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

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

OK, since yo= u don=E2=80=99t allow network extension, and you don=E2=80=99t want to supp= ort SLAAC in your environment, presumably you can implement outside of the = recommendations contained in this draft. AIUI, this is an informational / b= est 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 acc= ept 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 DH= CPv6, while
ensuring that connected devices can support pretty much any = use case,
including hosts forming unlimited addresses, plugging in route= rs, and doing
a moderate amount of network extension with end-to-end con= nectivity 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? Unsupp= orted, not allowed things should be hard to get working. If someone tries t= o extend the network (while not allowed to do so), I want his/her attempt t= o 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 corpo= rate network? Network extension in corporate networks is not a common use c= ase, in my opinion.

Network extension within policy is not a common use case.

As someone whose job has regularly included tracking s= uch 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 w= ill 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, an= d a major pain to identify and resolve.

At least i= f the host is asking for a /64 and extending the network, you have some vis= ibility into what is happening, even if the exact topology isn=E2=80=99t 10= 0% 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 ar= e not getting
/64s from me. If your implementa= tion 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 i= s 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 b= asis to reconsider BYOD policies.
<= /blockquote>

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

Each network operator and the hosts administrators usi= ng 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, th= is can go fairly smoothly. In environments where host administration is the= Wild West of software developers doing whatever they think they need witho= ut regard to network or corporate policy, this can be a much bigger adventu= re. In environments where the networking team went to the BOFH school of ne= twork management, this can also be a much bigger adventure.

<= /div>
I=E2=80=99ve seen examples of all three of these scenarios. The o= bvious worst case is Wild West developers + a BOFH trained network team (an= d I=E2=80=99ve seen that too).

This is why= we need a fixed boundary - otherwise we end up with a race to
the botto= m 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, an= d 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 i= f that will work. Just like you say, "you can have all the /80s you
want, but yo= u're not getting /64s", some other operators saying, "you can
have all t= he /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
chang= ing SLAAC.

Do you really think that? Yes, there will be som= e networks that will use IPv4 principles and try to conserve IP space so mu= ch that they try to give too little to clients. However, many more are adhe= ring to recommendations made by IETF or RIR. At ISP, I give /56 to resident= ial 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 admin= istrator 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 the= y request up to a /60. The won=E2=80=99t give anything shorter than /60 to = a residential customer.

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

There=E2=80=99s a gu= y 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=9Cmo= st=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 re= sults 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 pref= ix size, but I wouldn=E2=80=99t oppose a draft requiring support for greate= r 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 v= ariety of residential gateways, you=E2=80=99ll see MSOs treat that as an ex= cuse to start handing out /76 instead of /60.

This draft is a bit different. If every device requi= red a /64 and it would like to extend the network, I would be pushed around, and I hate tha= t. Clients would push me to give them /64, SCO would push me on network sec= urity 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 addition= al space.

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

_____________________________= __________________
v6ops mailing list
v6ops@ietf.org
https://www.i= etf.org/mailman/listinfo/v6ops


********= **************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--Apple-Mail=_3AEE246E-836E-4A35-AECC-0DDFD14E4AA4--