We are simply documenting existing APNIC policy in this draft.
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? I've used various parts of 220/8 address space for my IPv4 multihoming examples (because there is no such prefix in IPv4), and no one has ever complained about me taking a /20 (the RIR minimum allocation) and splitting into lots of pieces to demonstrate multihoming. But that's my experience...
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.
philip --
At 20:29 27/02/2003 -0800, Michel Py wrote:
> A New Internet-Draft is available from the on-line > Internet-Drafts directories. > Title : IPv6 Documentation Address > Author(s) : G. Huston, A. Lord, P. Smith > Filename : draft-huston-ipv6-documentation-prefix-00.txt
This text is a good beginning, but as I mentioned earlier a single /32 is not enough to document multihoming scenarios.
A site receives connectivity from 3 LIRs; the site is assigned three /48s. It would be confusing to make these three /48 part of the same /32 as lots of people would assume that a LIR gets a /32 as it is current policy.
Example: Prefix assigned by LIR 1: 2001:0DB8:1234::/48 Prefix assigned by LIR 2: 2001:0DB8:5678::/48 Prefix assigned by LIR 3: 2001:0DB8:ABCD::/48 Something does not register here, as people might assume that LIRs 1,2 and 3 are tier-2 or -3 LIRs that all get transit from a bigger tier-1 LIR that has been allocated 2001:0DB8::/32 (which defeats half of the reasons to multihome).
The purpose of the documentation prefix is double: 1. Avoid using addresses that could be assigned to a site. 2. Avoid using things such as: Prefix assigned by LIR 1: 2001:x:y::/48 Prefix assigned by LIR 2: 2001:a:b::/48 Prefix assigned by LIR 3: 2001:c:d::/48
Editorial: including the email addresses of the authors in the text would not hurt anyone.
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] --------------------------------------------------------------------
