Re: [v6ops] WGLC for draft-ietf-v6ops-rfc3849-update-01

Distilling all of this down, I’m thinking perhaps we could burn less space and still achieve the desired result with just:

	Keep 2001:db8::/32
	Add 1:ab00::/24
	Add d:0c00::/24

Thoughts?

Owen

> On Dec 14, 2023, at 08:40, Ed Horley <ed@hexabuild.io> wrote:
> 
> maybe in the same vein, adding:
> 01ab::/16 shortened to 1ab::/16 for lab?
> it gives us another prefix but looks unique and different enough from 2001:db8::/32 and the d0c::/16 also
> 
> On Tue, Dec 12, 2023 at 8:50 AM Ed Horley <ed@hexabuild.io <mailto:ed@hexabuild.io>> wrote:
>> I agree, d0c::/16 and a few more prefixes would be super helpful for the work we are doing regularly.
>> 
>> On Tue, Dec 12, 2023 at 8:38 AM Owen DeLong <owen=40delong.com@dmarc.ietf.org <mailto:40delong.com@dmarc.ietf.org>> wrote:
>>> I have no problem with d0c::/16, but I think there is still a case to be made to have some disparate prefixes. 
>>> 
>>> Owen
>>> 
>>> 
>>>> On Dec 12, 2023, at 00:45, Tim Chown <Tim.Chown=40jisc.ac.uk@dmarc.ietf.org <mailto:40jisc.ac.uk@dmarc.ietf.org>> wrote:
>>>> 
>>>>  Hi,
>>>> 
>>>>> On 11 Dec 2023, at 18:15, David Farmer <farmer@umn.edu <mailto:farmer@umn.edu>> wrote:
>>>>> 
>>>>> I agree, d0c0::/12 seems gratuitous to me as well. On the other hand, if we went with d0c0::/20, who would ever want an allocation from the rest of d0c0::/12? Not me!
>>>>> 
>>>>> I think I’d prefer 0d0c::/16, which can also be written d0c::/16, while still somewhat gratuitous, it’s better than a whole /12. And, again if we only went with d0c::/20, who would ever want an allocation from the rest of d0c::/16? Therefore, reserving the whole /16 for documentation eliminates that dilemma.
>>>> 
>>>> If that’s possible, that would seem equally good; it’s clear what it is, not in the existing 2000::/3 range or under the f space.  I think d0c::/16 would be a nice compromise from what’s been discussed.
>>>> 
>>>> Tim
>>>> 
>>>>> Thanks 
>>>>> 
>>>>> On Mon, Dec 11, 2023 at 09:06 Warren Kumari <warren@kumari.net <mailto:warren@kumari.net>> wrote:
>>>>>> 
>>>>>> On Mon, Dec 11, 2023 at 8:58 AM, Momoka Yamamoto <momoka.my6@gmail.com <mailto:momoka.my6@gmail.com>> wrote:
>>>>>>> I have a clarifying question purely out of curiosity and to be able to learn how the IETF operates.
>>>>>>> What is the formal way of choosing the actual prefix?
>>>>>>> Will the AD (Warren) talk to IANA (and the RIRs if necessary) and make a decision?
>>>>>>> Would this be done after the IETF Last Call?
>>>>>> 
>>>>>> 
>>>>>> After IETF LC (during IESG Eval) the IANA will review the "IANA Considerations" section, and will let us know if they understand / are able to execute whatever is in that section. After the document is all approved, the IANA selects the actual codepoint (prefix in this case).
>>>>>> 
>>>>>> I'm not actually sure what their process is for assignment from the IPv6 Global Unicast Address registry, but I expect that they will take the fact that this is for documentation into account. I personally think that d0c0::/12 would be funny/entertaining/cool — but it does also feel like it would be gratuitous…
>>>>>> 
>>>>>> W
>>>>>> 
>>>>>>> 
>>>>>>> The answer to this question will not affect my support for this draft, which I have stated at the beginning of this WGLC.
>>>>>>> 
>>>>>>> On Fri, Dec 8, 2023 at 6:36 PM Tim Chown <Tim.Chown=40jisc.ac.uk@dmarc.ietf.org <mailto:40jisc.ac.uk@dmarc.ietf.org>> wrote:
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> There’s always the option to add further documentation space later; the /20 is just fixing the problem most people have now in being limited to the 2001:db8::/32 range, and wanting to use large examples and with two more clearly distinct example provider prefixes.
>>>>>>>> 
>>>>>>>> I would support using something more clearly not a (current) production prefix for this.  In the past, 3ffe::/16 and 5f00::/8 (I didn’t know this, one, but it’s in the IANA registry) were used for the 6bone, something more obvious like that, perhaps outside 2000::/3, would be better. Though using d0c0::/12 might be gratuitous and put a big hole in future allocations one day if we run through four more /3’s sooner than expected.
>>>>>>>> 
>>>>>>>> Tim
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> v6ops mailing list
>>>>>>>> v6ops@ietf.org <mailto:v6ops@ietf.org>
>>>>>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>>>>> 
>>>>>>> _______________________________________________ 
>>>>>>> v6ops mailing list 
>>>>>>> v6ops@ietf.org <mailto:v6ops@ietf.org> 
>>>>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>>> _______________________________________________
>>>> v6ops mailing list
>>>> v6ops@ietf.org <mailto:v6ops@ietf.org>
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>> _______________________________________________
>>> v6ops mailing list
>>> v6ops@ietf.org <mailto:v6ops@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/v6ops
>> 
>> 
>> --
>> Ed Horley
>> ed@hexabuild.io <mailto:ed@hexabuild.io> | (925) 876-6604
>> Advancing Cloud, IoT, and Security with IPv6
>> https://hexabuild.io <https://hexabuild.io/>
>> And check out the IPv6 Buzz Podcast at https://packetpushers.net/series/ipv6-buzz/
> 
> 
> --
> Ed Horley
> ed@hexabuild.io <mailto:ed@hexabuild.io> | (925) 876-6604
> Advancing Cloud, IoT, and Security with IPv6
> https://hexabuild.io <https://hexabuild.io/>
> And check out the IPv6 Buzz Podcast at https://packetpushers.net/series/ipv6-buzz/