Subject: (ngtrans) Re: pTLA 3FFE:FFF0::/28 for test & example use per draft-blanchet-ipngwg-testadd-00.txt, closes 20Jun01

From: [email-masked]
Date: Thu, 07 Jun 2001 12:00:02 +0900

(moved from 6bone mailing list to ngtrans, as the email talks about the
	draft)

>6bone folk,
>You can see from the email exchange below, and the draft at:
><http://search.ietf.org/internet-drafts/draft-blanchet-ipngwg-testadd-00.txt>
>"Abstract To reduce the likelihood of conflict and confusion, an IPv6 
>prefix is reserved for use in private testing or as examples in other RFCs, 
>documentation, and the like. Since site local addresses have special 
>meaning in IPv6, these cannot be used in many example situations and are 
>confusing. Instead, an IPv6 prefix is reserved in the range of the test 
>address space."

	we have to make it VERY sure that the purpose of the block
	(3ffe:fff0::/28) is different from RFC1918 private address space.
	i hope that 01 draft to have more warnings to make it clearer.

itojun

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 06 Jun 2001 23:16:06 -0400

>         (3ffe:fff0::/28) is different from RFC1918 private address space.

this is a very valid point.

>         i hope that 01 draft to have more warnings to make it clearer.

is adding a warning in the document sufficient? Can we do something else?

Marc.

---

From: Keith Moore <[email-masked]>
Date: Thu, 07 Jun 2001 00:24:35 -0400

as far as I can tell, this is very close to the same purpose as RFC 1918.
I don't know why we would expect different results this time around.

instead, why don't we encourage folks who are doing testing to get an IPv4
address from somewhere (surely they can find one...) and use the 6to4
address block derived from that IPv4 address?  they don't have to exchange
traffic between those nodes and the rest of the network if they don't
want to.  but if they later decide they do want to exchange traffic
using those addresses, it will be possible for them to do so.

let's also make sure to tell them to not build those 6to4 addresses
out of RFC 1918 addresses.

Keith

(this also illustrates a problem with address allocation guidelines - 
folks need to be able to get globally-unique address blocks for use on
their private nets even if they will never route them on the
public internet - otherwise they will be unable to set up private
links between their private networks without either renumbering or NATs)

---

From: [email-masked]
Date: Thu, 07 Jun 2001 13:28:10 +0900

>using those addresses, it will be possible for them to do so.

	we have a separate draft for this -
	draft-itojun-ipv6-local-experiment-02.txt.

	marc's one is more like "how to write example configuration down onto
	manual pages".  since we don't know what IPv4 address the readers
	would use, we cannot really generate 6to4 prefix.

itojun

---

From: Keith Moore <[email-masked]>
Date: Thu, 07 Jun 2001 01:08:25 -0400

> 	draft-itojun-ipv6-local-experiment-02.txt.

good. thanks for pointing that out.

> 	would use, we cannot really generate 6to4 prefix.

a.  perhaps this could be made clearer in the next version?
    the current draft implies more than once that these addresses 
    could be used for testing or test networks, which is pretty
    close to saying they can be used for private operational networks.
    test networks sometimes evolve into operational networks if the
    test is successful.

b.  I wonder if 3FFE:FFF0:: addresses make good examples, since they 
    will "look different" than addresses in typical use (outside of
    the 6bone).  Also, might it be useful to have multiple example 
    prefixes so that in examples citing addresses from different parts 
    of the net the different prefixes would be easily distinguishable?

Keith

---

From: Alain Durand <[email-masked]>
Date: Wed, 06 Jun 2001 23:03:42 -0700

>     test networks sometimes evolve into operational networks if the

The real value of Marc's draft is to give a prefix that we can use in example,
like in RFCs, books, white paper, config example, etc...
like the 555 area code in the movies.
Having address space for test network is a very different thing.
We have itojun's draft for that or we can suggest to use site local addresses.
I would like to suggest to Marc to remove any reference to test networks in 
a future -01 draft.

>     of the net the different prefixes would be easily distinguishable?

All we need is something that looks like a real IPv6 address but that is not
allocated to anyone. I do not think that the fact that the address starts with
a 2 or a 3 is relevant. This is the reason why I suggested 3ffe:5550::/28
to maintain the parallel with the 555 area code.
Also reserving a /28 prefix is large enough so any technical writer
can carve as many prefixes as needed out of it.

         - Alain.

---

From: [email-masked]
Date: Thu, 07 Jun 2001 15:02:01 +0900

>can carve as many prefixes as needed out of it.

	I personally like 3fff:fff0::/28 than 3ffe:5550::/28, as 555 area code
	is not universal concept (this is only for US/hollywood movies).
	also 3ffe:5550::/28 does not follow /24 - /28 rule under 3ffe::/16
	(/28 has to have 16th bit set).

itojun

---

From: Keith Moore <[email-masked]>
Date: Thu, 07 Jun 2001 02:06:29 -0400

> I would like to suggest to Marc to remove any reference to test networks in

I concur, and I would like to further suggest that the next draft 
specifically state that these addresses are not intended for testing 
or for operational networks, and referring the reader who wants
test or private network addresses to itojun's document.

Keith

---

From: Nathan Lutchansky <[email-masked]>
Date: Thu, 7 Jun 2001 02:43:51 -0400 (EDT)

> test or private network addresses to itojun's document.

I also concur, and I would like to even further suggest that the next
draft state that anyone writing documentation or manuals that contain
these addresses in examples should explicitly state in their documents
that these addresses are not to be used, even for testing, and that any
device configured to use these addresses should be considered
non-functional.  -Nathan

- -- 
+-------------------+---------------------+------------------------+
| Nathan Lutchansky | [email-masked] |  Lithium Technologies  |
+------------------------------------------------------------------+
|  I dread success.  To have succeeded is to have finished one's   |
|  business on earth...  I like a state of continual becoming,     |
|  with a goal in front and not behind. - George Bernard Shaw      |
+------------------------------------------------------------------+

---

From: Dirk Ooms <[email-masked]>
Date: Thu, 07 Jun 2001 11:51:53 +0200

Would it be good to also reserve a range of multicast addresses for the
same purpose?

dirk

-- 
Dirk Ooms                       mailto:[email-masked]
                                tel:+32 3 2404732
Network Strategy Group (NSG)    http://aww.alcatel.com/nsg
Alcatel                         http://www.alcatel.com

---

From: "Brian Haberman" <[email-masked]>
Date: Thu, 07 Jun 2001 09:01:49 -0400

If you apply the mechanism defined in
draft-ietf-ipngwg-uni-based-mcast-01.txt,
Marc already has a range of multicast addresses.

Brian

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 07 Jun 2001 09:16:44 -0400

- in order to limit the number of copies of mailing lists and with the fact 
that the membership of ipng|ngtrans|6bone are probably very similar, can we 
discuss this in one mailing list? proposing ngtrans for now.

- Brian (or ipngwg chairs), is this safe to add a section to my draft about 
multicast and just refer to yours? Is your draft going to proposed  later?

Marc.

---

From: "Brian Haberman" <[email-masked]>
Date: Thu, 07 Jun 2001 09:23:24 -0400

Marc,

> discuss this in one mailing list? proposing ngtrans for now.

NGTRANS works for me.

> multicast and just refer to yours? Is your draft going to proposed  later?

This doc passed IPng WG last call prior to the Minneapolis IETF
meeting.  It is supposed to be on its way to the IESG for review.

Brian