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 PROTECTED] --------------------------------------------------------------------
