Subject: RE: I-D ACTION:draft-huston-ipv6-documentation-prefix-00.txt

From: "Michel Py" <[email-masked]>
Date: Mon, 3 Mar 2003 20:50:30 -0800

Philip,

> Philip Smith wrote:
> We are simply documenting existing APNIC policy in this draft.

I understand, and documenting it is nice _and_ necessary; until a few
days ago I was not aware of that prefix (and I would bet that half of
this mailing list was not either). To make myself perfectly clear I
would rather see this doc shipped with that one /32 now and be upgraded
later if other documentation prefixes pop up vs. waiting for more
prefixes to be assigned to documentation.

In other words: documenting APNIC policy is nice, APNIC deserves kudos
for assigning a /32 to the purpose of documentation prefixes, and your
draft should, if possible, go further than what is already there but
ship as-is if nothing new is on the horizon.

> Having a large block to help document multihoming examples makes
> sense, but I don't see anything wrong with the example you say is
> a problem. Yes, operationally it might be a bit odd, but for
> documentation? Would there be confusion in the minds of people who
> are reading the documentation?

There are two aspects to this:

1. This is what I'm worried about, yes. The /32 LIR pseudo boundary is
way too convenient to assume that people won't assume it's there. The
sad truth is that more than 50% of "engineers" that do IPv4 assume that
a subnet mask is always 255.255.255.0; we have to understand the fact
that the same people will assume: /64 subnet prefix, /48 site prefix,
/32 LIR prefix. I know and so do you that the ":" is not a boundary, but
in people's minds it will be one.

A /32 in the IPv6 space is not even a drop in the sea. Two /32s are
still a drop in the sea. I fully agree with conservation principles, but
the fact of the matter is that I already have multiple /48s for my home
setup, so the argument about allocating a few /32s instead of a single
one is moot.

In other words: it is my evaluation that a _few_ /32 prefixes, instead
of a single one, are a worthy trade-off between "waste" of IPv6 address
space and elegance and "feeling realistic" documentation.

2. Documentation is one thing, lab-ing a scenario is quite another. Call
me sick if you want, but when I do a 20-router 3-LIR simulation lab, I
do configure it the way it should be in the real world, which is that
each LIR gets a /32 that is an aggregate of the IGP's space, each ptp
link gets a /64, each "site" (thanks to the guy that invented the
loopback interface) a /48, etc. My point here is that I am currently
hijacking Global Unicast space for lab purposes, and if a single /32 is
what I get for lab I will continue to do so.

The point is not why I need a /29 to lab a scenario; I can fit it in a
/48 if need be. The point is that a good documentation and a good lab a)
does not hijack public space and b) looks like the real McCoy with the
addresses being different, not the prefixes.

> Anyway, if folks think that a larger address block should be
> proposed for documentation, let us know what the number should
> be and why it should be so, and I will be more than happy to
> propose it to the next APNIC Open Policy Meeting as an
> amendment to the existing policy.

IMHO, an additional /32 from the APNIC space, plus two from the ARIN
space and two from the RIPE space (all of them preferably not
contiguous) would be good.

Two /32s from an IETF request directly to the IANA would look good too,
but given the time Marc Blanchet's draft has been lost in space I will
not loose sleep over them.

Michel.

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "Michel Py" <[email-masked]>
Date: Tue, 4 Mar 2003 06:59:30 -0800

> Geoff Huston wrote:
> Does that mean want to propose to use 2001:D0C0::/32 as well?

Gee, even I could remember that one! 2001:D0C::/32 would be even nicer,
there are number of other alternatives such as 2001:2D0C::/32 and
2001:4D0C::/32.

Michel.