Subject: RE: Draft on a V6 documentation prefix

From: "Michel Py" <[email-masked]>
Date: Tue, 13 May 2003 18:11:57 -0700

Tim,

>> Michel Py wrote:
>> The trouble with using things such as XXXX:XXXX::/32 and
>> YYYY:YYYY::/32 is that they can't be configured on a router and
>> won't prevent the hijacking of a real prefix when labing the
>> case, which is what the documentation prefix tries to prevent
>> from happening.

> Tim Chown wrote:
> So if we do create this prefix, what's the difference between
> this and an allocated prefix for private use in networks?

Basically none.

> You're suggesting it's not a documentation prefix,

Not _only_ a documentation prefix.

> but a prefix for use in (disconnected) networks. Throw in
> v6 NAT and... ;)

This is a very valid point that has been made several times before.

It is clear that the documentation prefix is a prime candidate for
hijacking for NAT purposes. That being said, there are plenty of other
good candidates such as returned prefixes of 3ffe::/16, the entire
3ffe::/16 space after 6/6/6, 2002:RFC:1918::, a random prefix out of
unallocated space in the C000::/16 range, etc.

IMHO a _few_ /32 prefixes would be preferable for lab scenarios (for
reasons outlined earlier) and would not encourage NAT more than a single
one.

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: Robert Elz <[email-masked]>
Date: Wed, 14 May 2003 17:57:43 +0700

Date:        Tue, 13 May 2003 18:11:57 -0700
    From:        "Michel Py" <[email-masked]>
    Message-ID:  <[email-masked]>

  | It is clear that the documentation prefix is a prime candidate for
  | hijacking for NAT purposes.

I had always assumed that the point of specifying a specific prefix
as one to be used in documentation, would be that (good) implementations
would notice at attempt to configure this particular prefix (someone
copying examples from a manual) and refuse to allow it, with a message
something along the lines of:

	That prefix is an example intended for examples only.
	You need to get a prefix allocated from your provider, or ...
	and use that instead of the example prefix used in documentation.

Otherwise, there's little point having it.

If that happens, then this particular prefix turns out to be the one
prefix which is particularly unsuited for NAT (or other) hijacking.

kre