Subject: [v6ops] draft-ietf-v6ops-ipv6-discard-prefix-00 - IANA feeback

From: Joel jaeggli <[email-masked]>
Date: Wed, 09 Nov 2011 09:40:21 -0800

FYI we recieved the following feedback from IANA on
draft-ietf-v6ops-ipv6-discard-prefix-00, this was requested by the wg
chairs during the WGLC.

as noted the specical use prefix falls within 2000::/3 the global
unicast range. teredo for the record is 2001:0::/32.

joel

---

1. This assignment should come from the IANA IPv6 Special Purpose
Address Registry and not the IPv6 Address Space registry, as per RFC 4773.

2. Because of the change in registry, the IC section should indicate how
to complete the relevant cells in the table:

 - Assignment (name)
 - Termination Date (or never)
 - Purpose
 - Contact details
 - Routing scope

3. The IC section currently states that "The prefix should be allocated
from ::/3" and as we would be taking it from 2001:0000::/23 that
sentence is probably superfluous. If the author takes a shine to a
specific /64 from there he could let us know. Otherwise, I propose we
just take the numerically lowest /64, which would be immediately after
the TEREDO assignment. We could discuss this with the author in case he
has operational concerns with that.

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 11 Nov 2011 15:03:13 +0000

> has operational concerns with that.

As an author comment, the WG consensus at the last v6ops meeting was that 
the prefix should specifically not come from global unicast space. 
However, IANA would prefer if it were to come from the special purpose 
registry: 2001::/23.

Regardless of IANA's preferences, I'm still of the opinion that it would be 
better to keep to the WG preference.

Nick

---

From: Doug Barton <[email-masked]>
Date: Fri, 11 Nov 2011 13:57:01 -0800

On 11/11/2011 07:03, Nick Hilliard wrote:
> As an author comment, the WG consensus at the last v6ops meeting was
> that the prefix should specifically not come from global unicast space.

Not only do I disagree that what you're describing was the consensus,
but you're still mischaracterizing "global unicast space." Please see:

https://www.ietf.org/mail-archive/web/v6ops/current/msg09679.html

> However, IANA would prefer if it were to come from the special purpose

I retain a slight preference for Roger's idea of using the last /32 in
2000::/3 (3fff:ffff::/32). OTOH the only reason I can see not to pull it
from the SPR would be to avoid wasting space in that registry that could
eventually be put to a better purpose; so if the final decision is to go
that way I wouldn't object.

hth,

Doug

-- 

		"We could put the whole Internet into a book."
		"Too practical."

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: Joel jaeggli <[email-masked]>
Date: Sat, 12 Nov 2011 17:36:28 +0800

> that the prefix should specifically not come from global unicast space.

well, we solicted advice, and we recieved it...

If we belive that it should not come from the special purpose registry 
we should be prepared to justify that rfc4773 doesn't apply to the IESG.

To review the mailing list history the on our own, discussion looks 
something like the following:

We have one participant using the documentation region:

[email-masked]

In my implementation I have been using the IPv6 documentation prefix, 
2001:0DB8::/32, which I admit may be bad practice and make me out to be 
a bad boy, e pur si muove.  (Or, it works for me.)

Mark smith says:

Where your thoughts to have it come from within 2000::/3, which is
perhaps why you chose /32? I think it probably should come from outside
of it similar to ULAs, ::1 etc., because I don't think a discard
function is dependent on the Internet's global unicast addressing. Once
it's outside of 2000::/3, I'd think the chosen size can chosen based on
expected use, rather than trying to reasonably fit in with an existing
allocation scheme.

daniel rosen says:

/64s are far less likely to leak into the DFZ. As such, I'd favor
to settle on /64 if size doesn't matter for other reasons.

[email-masked]

It should be a ::/32 and should be taken from the very end of the same
2000::/3 we are currently using. To pick it from outside the current
used address may sound like a good idea, and may be tempting to make
it stand out from current addresses. But I'm more afraid that will
polute our next go on IPv6.

doug barton says:

I agree that 3fff:ffff::/32 is a good idea for this purpose. 3ff* is
more or less useless for general purposes anyway given the historical
Teredo usage.

I don't like the idea of using a prefix from a block outside 2000::/3,
since we have been operating under the assumption that if we screw
something up in this /3 that we can start over in one of the others. I'd
hate to cripple that premise.

erik kline says:

What about something from up near the ULA space?

keith moore says:

There's always {prefix}::dead:beef

fred baker says:

In BGP peering, one generally announces the set of prefixes associated 
with some set of communities, and accepts 2000::/3 or some set of more 
specific routes after a short list of exclusions. I thought I heard that 
it should be easy to fail to announce (eg to miss those communities) and 
that the same filter (2001::/3 plus future IANA allocations to the RIRs) 
should prevent acceptance if announced. That brings me to suggest that 
the /64 should be in either ::/3 or e000::/3, as we have various sets of 
addresses there that have those characteristics.

> Regardless of IANA's preferences, I'm still of the opinion that it would
> be better to keep to the WG preference.

which is fine