Subject: wrt: draft-blanchet-ipngwg-testadd-00.txt

From: Robert Elz <[email-masked]>
Date: Wed, 09 May 2001 19:08:16 +0700

I have no problem with the general idea of this draft (reserving
an address block to use in documentation, examples, etc), but the
address block chosen is the wrong one.

If an address block is to be picked for this, then it should be one
that is, on the face if it, not a valid address block, not just
a piece carved out of the regular address space, and which looks
just like everyone else's address (even if an expert can tell that
it is one that shouldn't be used).

I'd have thought the example learned from Sun's use of 192.9.200
as its documentation example would have made that clear - that was
equivalent to a reserved address (reserved by Sun, as one of their
addresses, rather than by IANA, but that's an irrelevant difference).
192.9.200 looks like a valid address, so lots of the world simply
copied it to their nets.   I suspect there are probably still large
numbers of nets numbered from that /24.

I don't have a particular alternative in mind, but just to throw
out a suggestion, something like 0000:DEAD::/48 (or /32 if needed)
would be a good example prefix to use.   It is already in the reserved
space, so doesn't need to be treated specially, though it should be
documented as being available for use in examples, and only in examples.

Or perhaps even 0000:FFFF:DEAD::/48 if you want to put something closer
to the end of an address "block".  Or 00FF:DEAD::/48 - you get the picture.

kre

--------------------------------------------------------------------
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: Bill Manning <[email-masked]>
Date: Wed, 9 May 2001 05:17:42 -0700 (PDT)

Itojin has a similar draft out. We beat him up about "snitching"
 a chunk from the WIDE delegation.

 We already have one dead space, the range that was used prior to 
 the 6bone. This was the "glue your ASN in and get your range"
 block that Postel, Deering, & Hindon (I think) put together.

% 
% I have no problem with the general idea of this draft (reserving
% an address block to use in documentation, examples, etc), but the
% address block chosen is the wrong one.
% 
% If an address block is to be picked for this, then it should be one
% that is, on the face if it, not a valid address block, not just
% a piece carved out of the regular address space, and which looks
% just like everyone else's address (even if an expert can tell that
% it is one that shouldn't be used).
% 
% I'd have thought the example learned from Sun's use of 192.9.200
% as its documentation example would have made that clear - that was
% equivalent to a reserved address (reserved by Sun, as one of their
% addresses, rather than by IANA, but that's an irrelevant difference).
% 192.9.200 looks like a valid address, so lots of the world simply
% copied it to their nets.   I suspect there are probably still large
% numbers of nets numbered from that /24.
% 
% I don't have a particular alternative in mind, but just to throw
% out a suggestion, something like 0000:DEAD::/48 (or /32 if needed)
% would be a good example prefix to use.   It is already in the reserved
% space, so doesn't need to be treated specially, though it should be
% documented as being available for use in examples, and only in examples.
% 
% Or perhaps even 0000:FFFF:DEAD::/48 if you want to put something closer
% to the end of an address "block".  Or 00FF:DEAD::/48 - you get the picture.
% 
% kre
% 
% --------------------------------------------------------------------
% 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]
% --------------------------------------------------------------------
% 

-- 
--bill

---

From: Robert Elz <[email-masked]>
Date: Wed, 09 May 2001 19:48:40 +0700

Date:        Wed, 9 May 2001 05:17:42 -0700 (PDT)
    From:        Bill Manning <[email-masked]>
    Message-ID:  <[email-masked]>

  |  Itojin has a similar draft out.

I must have missed that one.

  |  We already have one dead space,

Fine - as I said, what space to use doesn't bother me (of the large
number of possibilities) - just that the one in this draft isn't it.

But it is even more clear now that it is a good idea to actually
document what address range is a good one to use for this purpose.

kre

---

From: [email-masked]
Date: Wed, 09 May 2001 21:53:39 +0900

>I must have missed that one.

	draft-itojun-ipv6-local-experiment-02.txt.
	01 mentions 3ffe:501:ffff::/48 (officially reserved from WIDE pTLA
	space) and 02 removes it.

itojun

---

From: Robert Elz <[email-masked]>
Date: Wed, 09 May 2001 20:35:01 +0700

Date:        Wed, 09 May 2001 21:53:39 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	draft-itojun-ipv6-local-experiment-02.txt.
  | 	01 mentions 3ffe:501:ffff::/48 (officially reserved from WIDE pTLA
  | 	space) and 02 removes it.

OK, yes, I did miss that (and 3 versions of it...)   For reasons I
don't understand I keep falling off the ietf lists, and miss lots of
announcements...

Your draft is for a completely different purpose than Marc's.   While
deleting the 3ffe:... addresses from it is better I think, it is far
less important that it be deleted from yours than it is from Marc's.

Yours needs what is realistically genuine address space, for it to work
as designed (there's no point discovering that your router won't route
illegal addresses - that's not very interesting information when your
point was to prove that things do work).

Marc's needs demonstrably "illegal" addresses, ones that cannot possibly
work - so they can be permanently recorded in manuals, etc, and never
cause any problems in the future.   The requirements should be that the
address syntax is correct, and that the addresses are patently bogus.

kre

---

From: Marc Blanchet <[email-masked]>
Date: Sat, 12 May 2001 09:25:39 -0400

- As Robert was saying about my draft, there is two issues:
  + do we agree on the idea of the draft?
   if yes, then find one address space which is the best one for that 
purpose. I don't care which one, I just proposed one. Any advice is 
appreciated.  For the sake of generality, we might want to reserve a range 
that is similar to a TLA, so that anyone would be able to use it for 
examples involving TLAs.
   if no, then forget the draft.

What is the opinion of the group?

Marc.