Subject: Re: I want to reclaim 192.88.99.0/24 - does anyone have a problem with that?

From: Erik Kline <[email-masked]>
Date: Thu, 12 Aug 2021 08:48:09 -0700

+6man

On Thu, Aug 12, 2021 at 8:39 AM Templin (US), Fred L <
[email-masked]> wrote:

> Hi, RFC3068 set aside the prefix 192.88.99.0/24 as the 6to4 Relay Anycast
> prefix, and
> then RFC7526 came along and deprecated that use. I would like to reclaim
> the prefix
> and use it for a different anycasting purpose - mostly within IPv4
> networks that would
> not be places where one would ordinarily find a 6to4 Relay router.
>
> RFC7526 Section 7 says:
>
>   "Redelegation of this prefix for any use requires justification via an
> IETF Standards
>     Action [RFC5226]."
>
> and I have a document that is aligned toward IETF Standards Track that
> would do
> precisely this. This would be "Plan A", but if that would be unworkable
> then we may
> need to press forward with a "Plan B".
>
> There are those of you out there who know exactly what this is about and
> some have
> even made remarks about it during recent IETF working group presentations.
> Now is
> the time to speak up and put all concerns on the table - silence is no
> longer an option.
>
> Thanks - Fred
>

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 12 Aug 2021 16:11:56 +0000

FYI, responding to add 6man to the distribution.

> -----Original Message-----
> From: ietf [mailto:[email-masked]] On Behalf Of Templin (US), Fred L
> Sent: Thursday, August 12, 2021 8:38 AM
> To: IETF discussion list <[email-masked]>
> Cc: Hunter (US), Mark W <[email-masked]>; Nache (US), Samuel J <[email-masked]>
> Subject: I want to reclaim 192.88.99.0/24 - does anyone have a problem with that?
> 
> Hi, RFC3068 set aside the prefix 192.88.99.0/24 as the 6to4 Relay Anycast prefix, and
> then RFC7526 came along and deprecated that use. I would like to reclaim the prefix
> and use it for a different anycasting purpose - mostly within IPv4 networks that would
>   "Redelegation of this prefix for any use requires justification via an IETF Standards
>     Action [RFC5226]."
> 
> and I have a document that is aligned toward IETF Standards Track that would do
> precisely this. This would be "Plan A", but if that would be unworkable then we may
> There are those of you out there who know exactly what this is about and some have
> even made remarks about it during recent IETF working group presentations. Now is
> the time to speak up and put all concerns on the table - silence is no longer an option.
> 
> Thanks - Fred

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 12 Aug 2021 17:15:45 +0100

the prefix still appears in the public Internet DFZ.  This may cause 
problems if it's redelegated.  Would a different address range not be 
better under the circumstances?

Nick

Templin (US), Fred L wrote on 12/08/2021 17:11:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Ted Hardie <[email-masked]>
Date: Thu, 12 Aug 2021 17:16:54 +0100

A pointer to the draft would be helpful,

thanks,

Ted

---

From: "Dale W. Carder" <[email-masked]>
Date: Thu, 12 Aug 2021 11:30:47 -0500

Thus spake Nick Hilliard ([email-masked]) on Thu, Aug 12, 2021 at 05:15:45PM +0100:
> problems if it's redelegated.  Would a different address range not be better
> under the circumstances?

And note that in rfc7526 section 6, there was not explicit direction to
stop announcing it in the DFZ.  That would have to be updated before it 
could be redelegated.

Dale

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 12 Aug 2021 17:00:25 +0000

Hi, please excuse the aggregate post but not all messages that are hitting the lists
are showing up in my inbox.

To Nick and Dale, yes thank you for noting that the prefix is still populated in the
DFZ. However, there are two mitigating factors - first, the new standard in question
would not attempt to use an address from the prefix out in the open Internet; it
would only use an address from the prefix in a private-use (or otherwise stub)
IPv4 Internetwork. Second, the new standard calls for use of a different IPv4
address from the prefix, i.e., instead of the 192.88.99.1 specified in RFC3068.
So, even if a node were misconfigured to send an anycast discovery in the open
Internet the specific address would not be recognized by any 6to4 Relays and the
anycast discovery request would simply black hole.

To Ted who asked about the specific document reference, it is here:

https://www.ietf.org/archive/id/draft-templin-6man-omni-36.txt

To John who mentioned the great study on sunsetting the transition mechanisms,
thanks for the detailed analysis of the state of affairs in the wild. I think given the
points that I related to Nick and Dale above, however, it would seem that any
potential conflicts would be avoided?

Thanks - Fred

> From: Dale W. Carder [mailto:[email-masked]]
> Sent: Thursday, August 12, 2021 9:31 AM
> To: Nick Hilliard <[email-masked]>
> Cc: Templin (US), Fred L <[email-masked]>; Hunter (US), Mark W <[email-masked]>; 6man WG
> <[email-masked]>; IETF discussion list <[email-masked]>; Nache (US), Samuel J <[email-masked]>
> Subject: [EXTERNAL] Re: I want to reclaim 192.88.99.0/24 - does anyone have a problem with that?
> 
> EXT email: be mindful of links/attachments.
> 
> 
>

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 12 Aug 2021 18:08:35 +0100

Templin (US), Fred L wrote on 12/08/2021 18:00:
> I think given the

in general, special purpose address blocks are assigned by IANA. There's 
nothing in the draft that requires 192.88.99.0/24, and given that it's 
still visible to some degree in the dfz it would probably be advisable 
to avoid using it.  Do you have a specific reason why 192.88.99.0/24 
would work where another range wouldn't?

Nick