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

[Brian E Carpenter <[e-mail]>]

On 15-Dec-23 20:16, Owen DeLong wrote:
> I’m willing to bet that if these prefixes are allocated to doc in an rfc, the python library and others will be updated accordingly.

Certainly; I'm not so much worried about generic libraries as about individual coding efforts.

> Obvious to humans and to routers that have been set to treat GUA as 2000::/3.

3000::1 is a valid GUA, though. I don't think there is any way to handle documentation prefixes except as a special case.

    Brian


> 
> Owen
> 
> 
>> On Dec 14, 2023, at 22:49, Mark Smith <[e-mail]> wrote:
>>
>> 
>>
>>
>> On Fri, 15 Dec 2023, 11:53 Owen DeLong, <owen=[e-mail] <mailto:[e-mail]>> wrote:
>>
>>
>>
>>     > On Dec 14, 2023, at 16:47, Brian E Carpenter <[e-mail] <mailto:[e-mail]>> wrote:
>>     >
>>     > On 15-Dec-23 11:08, Owen DeLong wrote:
>>     >> 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
>>     >
>>     > I object to polluting 0000::/8 for the sake of eye candy addresses. Who knows what future generations might want to do with this space? IMHO we should make the assignment(s) in 2000::/3.
>>
>>     Part of the point of this is to get it OUT of 2000::/3 so that it’s completely obviously not GUA.
>>
>>     I’m fine with putting it in virtually any other /3 you like,
>>
>>     but I think I am not the only one who likes the idea of it NOT being in 2000::/3.
>>
>>     > (Also, it wouldn't amaze me if using 0000::/8 revealed unexpected bugs due to false assumptions by programmers.)
>>
>>     The point of these is to provide prefixes for documentation examples that DO NOT get loaded into routers,
>>
>>
>> That doesn't really work, people will try things and if they appear to work they assume nothing is wrong (like 1/8 was abused, and I've since seen 1::/<can't remember> being abused on a production IPv6 network.)
>>
>> An idea to prevent a documentation prefix from ever working on implementations was to intentionally make the prefix invalid, and then have a declaration when ever it is used that is an invalid prefix for documentation purposes only and a different prefix will be needed for deployment.
>>
>> A simple way to create an invalid documentation prefix that would be to include a 'g' in the prefix since it is an invalid hexadecimal digit.
>>
>> A prefix of g000::/4 would solve almost every documentation and example purpose, except perhaps when demonstrating and documenting how to be a (new/different) IANA and IETF for an entire IPv6 address space.
>>
>> Regards,
>> Mark.
>>
>>
>>     so how, exactly, would that become an issue?
>>
>>     Owen
>>
>>     >
>>     >   Brian
>>     >
>>     >> Thoughts?
>>     >> Owen
>>     >>> On Dec 14, 2023, at 08:40, Ed Horley <[e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> 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=[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> 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=[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>>     >>>>
>>     >>>>         Hi,
>>     >>>>
>>     >>>>>        On 11 Dec 2023, at 18:15, David Farmer <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> 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 <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>>     >>>>>
>>     >>>>>
>>     >>>>>            On Mon, Dec 11, 2023 at 8:58 AM, Momoka Yamamoto <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> 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=[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> 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
>>     >>>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
>>     >>>>> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops> <https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>>
>>     >>>>>
>>     >>>>>                _______________________________________________
>>     >>>>>                v6ops mailing list
>>     >>>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
>>     >>>>> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops> <https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>>
>>     >>>>>
>>     >>>>>
>>     >>>>
>>     >>>>        _______________________________________________
>>     >>>>        v6ops mailing list
>>     >>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
>>     >>>> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops> <https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>>
>>     >>>        _______________________________________________
>>     >>>        v6ops mailing list
>>     >>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
>>     >>> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops> <https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>>
>>     >>>
>>     >>>
>>     >>>
>>     >>>    --     Ed Horley
>>     >>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>| [phone]
>>     >>>    Advancing Cloud, IoT, and Security with IPv6
>>     >>> https://hexabuild.io <https://hexabuild.io> <https://hexabuild.io/ <https://hexabuild.io/>>
>>     >>>    And check out the IPv6 Buzz Podcast at https://packetpushers.net/series/ipv6-buzz/ <https://packetpushers.net/series/ipv6-buzz/> <https://packetpushers.net/series/ipv6-buzz/ <https://packetpushers.net/series/ipv6-buzz/>>
>>     >>>
>>     >>>
>>     >>>
>>     >>> --
>>     >>> Ed Horley
>>     >>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>| [phone]
>>     >>> Advancing Cloud, IoT, and Security with IPv6
>>     >>> https://hexabuild.io <https://hexabuild.io> <https://hexabuild.io/ <https://hexabuild.io/>>
>>     >>> And check out the IPv6 Buzz Podcast at https://packetpushers.net/series/ipv6-buzz/ <https://packetpushers.net/series/ipv6-buzz/> <https://packetpushers.net/series/ipv6-buzz/ <https://packetpushers.net/series/ipv6-buzz/>>
>>     >> _______________________________________________
>>     >> v6ops mailing list
>>     >> [e-mail] <mailto:[e-mail]>
>>     >> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
>>
>>     _______________________________________________
>>     v6ops mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
>>