Subject: (ngtrans) Re: again: draft-blanchet-ipngwg-testadd-00.txt

From: Marc Blanchet <[email-masked]>
Date: Wed, 27 Jun 2001 12:33:00 -0400

At/À 22:41 2001-06-27 +0700, Robert Elz you wrote/vous écriviez:
>It has been almost 2 weeks now since I suggested fe00::/9 as the
>prefix to use in Marc's draft to use for examples in doc and such.
>
>Aside from having my notational stupidity pointed out, there's been
>no comment at all on that suggestion.
>
>So, can we take it as accepted that that address block is now reserved
>for this purpose, and Marc can go ahead and send in an updated version
>of his draft using that as the prefix?

- a new draft was issued but the filename was changed with the advice of 
the ngtrans chairs. (draft-blanchet-ngtrans-exampleaddr-00.txt)
- I announced it in ngtrans list two days ago.
- the discussion of this draft is moved to ngtrans. Could anybody please 
_not_ reply to ipng so we will avoid multiple cross-postings. (I kept ipng 
so ipng people can see the answer).
- the suggestion of the ngtrans chairs was to use 3ffe:ffff::/32. I was for 
something else (i.e. 3ffe:ff00::/24), but I loose... ;-))

>The draft would contain an IANA considerations section that requests
>IANA to list that address block as "reserved for use in documentation"
>or similar.

this was already in the first version of the draft and kept. Alain Durand 
told me that he is looking at it (don't know what that means, but I'm 
expecting modifications of the text).

Marc.

PS. thanks for all comments!

>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: Alain Durand <[email-masked]>
Date: Wed, 27 Jun 2001 11:00:20 -0700

>>prefix to use in Marc's draft to use for examples in doc and such.

I'll keep the discussion in NGtrans.

The reason why I'd like to have this prefix under 3ffe::/16 is that
we already have the delegation here, thus the is no need to ask for 
something new.
In my opinion, the main reason to want something outside of 3ffe::/16 would 
be if the 6bone
prefix was to be reclaimed and reassigned, and I do not expect such an 
event to occur
anytime soon.

As about prefix length, /9 seems to me overkill and a real waste of address 
space.
The IPv6 address space is very large, but we must take great care of it, as any
fixed sized resource, as large as you want, can be exhausted by un-prudent
allocation.

The intend of Marc's draft is to document networks and backbone, so there is
a need to reserve something larger than /48. Reserving a /32 seems to me
large enough to achieve that goal without wasting to much space.

         - Alain.

---

From: Robert Elz <[email-masked]>
Date: Thu, 28 Jun 2001 01:53:59 +0700

Date:        Wed, 27 Jun 2001 11:00:20 -0700
    From:        Alain Durand <[email-masked]>
    Message-ID:  <5.1.0.14.0.20010627104811.00b0bfa0@jurassic>

  | I'll keep the discussion in NGtrans.

Well, OK, though I think that the documentation of IPv6 (I mean end-user
doc) is just as important as the code, and not at all related to
transition, so I'm not sure why it would be here.   But where the
discussion takes place doesn't matter much to me.

  | The reason why I'd like to have this prefix under 3ffe::/16 is that
  | we already have the delegation here, thus the is no need to ask for
  | something new.

That's bogus.   We don't have to ask - we (that is, a subset of us, which
doesn't include me really) invented the whole thing, and have already set
aside blocks for various purposes.   We can do the same again.   All we have
to ask for is that the assignment be recorded - that's no big burden.

  | In my opinion, the main reason to want something outside of 3ffe::/16 would
  | be if the 6bone prefix was to be reclaimed and reassigned,

No, that's not it (though I guess it is a small side issue for the far
future).

The reason is so that addresses used in doc simply don't look at all like
addresses used in real life - that is, it is trivial to distinguish one
from another.  A prefix carved out of 3ffe::/16 (even if it is 3ffe:ffff::/32)
is pretty similar to any other 6bone prefix.  It looks just the same,
people will copy the address from the doc, and configure it.   That's what
I really want to avoid happening (or at least, when they do, I'd like the
software to be able to say "invalid address" as soon as they attempt it).

  | As about prefix length, /9 seems to me overkill and a real waste of address
  | space.

There's something to that - but I think doc is worth it.  It allows all
levels of the hierarchy to be used in examples, to give config examples of
how NLAs talk to other NLAs and filter addresses, ...

The bigger concern, than the size, is that we might one day want fe00::/9
for more kinds of "local" addresses (to sit next to site local and link local).
That one when I initially thought about this I decided wasn't worth worrying
about - the alternative would be to use fc00::/8 for this, and leave fe00::/9
vacant.  That looked backwards, and to actually be a waste.

kre

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 27 Jun 2001 15:21:55 -0400

>     Message-ID:  <5.1.0.14.0.20010627104811.00b0bfa0@jurassic>

...

>from another.  A prefix carved out of 3ffe::/16 (even if it is 3ffe:ffff::/32)

something inside 2000::/3 has the property to be inside the current 
addressing architecture, which inherits all the boundaries defined (/64 for 
links, /48 for sites) and makes the examples real and conformant to the 
spec.  This is why I like inside 3ffe::/16.

>people will copy the address from the doc, and configure it.

which will result in "no problem" since it would be reserved and nobody 
else will use it since it would be registered.

>   That's what

would be great, but to me, it is not enough strong argument.

>how NLAs talk to other NLAs and filter addresses, ...

we agree on this. I was supporting a /24, but there is no support by the 
ngtrans chairs. So we loose, unless they change their mind!
Again, I'm ok with anything defined, which is much better than nothing 
defined. So I prefer a /32 than nothing.

Marc.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 27 Jun 2001 23:13:55 +0300 (EEST)

> vacant.  That looked backwards, and to actually be a waste.

IMO, fe00 written just so looks awfully close to fe80.

It would be nice if it was more clearly separate, like 10::/8 (analogy to
10.0.0.0/8); however using these kind of address blocks might not be
possible from the allocation point of view.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Robert Elz <[email-masked]>
Date: Thu, 28 Jun 2001 13:08:55 +0700

Date:        Wed, 27 Jun 2001 15:21:55 -0400
    From:        Marc Blanchet <[email-masked]>
    Message-ID:  <[email-masked]>

  | something inside 2000::/3 has the property to be inside the current
  | addressing architecture, which inherits all the boundaries defined (/64 for
  | links, /48 for sites) and makes the examples real and conformant to the
  | spec.  This is why I like inside 3ffe::/16.

Yes, it has that property.   It also has the property that it only applies
to addresses inside the 2000::/3 space, and hence if some other space is
defined, there would need to be a new prefix assigned out of that for
examples as well, and again for the next one.

Taking an "anonymous" prefix has the advantage that it has no assigned
rules or policies, so for the purposes of an example, you can simply
import whatever policies are appropriate for the example.

  | >is pretty similar to any other 6bone prefix.  It looks just the same,
  | >people will copy the address from the doc, and configure it.
  | 
  | which will result in "no problem" since it would be reserved and nobody
  | else will use it since it would be registered.

Hmm - you're assuming that there will be one person to mis-configure,
and no-one else ever will?   Really?   Or are you assuming that all the
routers will magically be configured to know this address is a bogus one,
and not forward packets around, and drop packets using it as a source
address?   (That would be easier to assume if there was just one well
defined prefix for addressing, and one away from the routable address
space, rather than one for 2000::/3 another for 4000::/3 another for
6000::/3 (etc) and each taken from somewhere inside the address space).

The people we're trying to deal with here are the ones who know nothing
about address registration, but do see in a book, RFC or product manual,
an example configuration given for how to achieve some effect.  And they
simply copy it, verbatim, changing not a character.   Lots of people get that
manual - several of them make the exact same verbatim copy.

That's what we need to be able to avoid - the only way I see to do that
is if the products know that the prefix is the "examples only" prefix and
simply refuse to take any notice of the user - insist instead to be given
a prefix that the user owns, to find that the user is going to have to
go beyond the duplicated documentation and discover just what has been
assigned to be used.

  | we agree on this. I was supporting a /24, but there is no support by the=20
  | ngtrans chairs. So we loose, unless they change their mind!

Um, no, that's not the IETF way.   And I doubt the chairs of ngtrans believe
that's how it works either.   If the WG decides that the prefix should be /24
(or /9 or something) that's what will be done.  That is, unless the chair
was reporting WG consensus.

I should add here, that I am not subscribed to ngtrans - it is important
work, but not work that I have time to participate in, so what has been going
on in this group I don't know (and so, please leave my address on any
replies...)

I still don't see what this issue has to do with ngtrans though, it still
really should be an ipngwg issue.  As best I can tell, the only reason it
moved to ngtrans was because of the suggestion to use some of the ngtrans
assigned address space, (ie: 6bone which is managed by ngtrans).  If the
decision is to use 3ffe::/15 space for this, then clearly which part of
that, and how much of it, are ngtrans issues.   Further, it would be out of
scope for ngtrans to decide on using some other part of the address space
(though recommending it to ipngwg would be fine).

So, unless it is presumed that part of 3ffe::/15 is the answer before the
issue is really even discussed, is there some other reason for ngtrans to
be deciding on this, rather than ipngwg?

  | Again, I'm ok with anything defined, which is much better than nothing
  | defined. So I prefer a /32 than nothing.

Yes, I agree with that.

Also, Pekka Savola said ...

  | IMO, fe00 written just so looks awfully close to fe80.

which is a fairly good point.   An alternative with most of the same
properties, and without that drawback, would be to use 1F00::/8
(or 1FFF::/16 or something between).    That is, the tail part of the
first /3 block (that contains the IPv4 stuff, and localhost, and all
the rest of that).   Its disadvantage is that there's no real good place
to carve it from while leaving the rest of the block as unaffected as
possible - taking it from the end leaves a fairly ugly (though still
usable) middle piece unassigned.

kre

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 28 Jun 2001 07:48:37 -0400

>was reporting WG consensus.

strictly speaking, you are right.
but if I count the number of people that have expressed opinions on the 
prefix to be chosen, then there is more people on the side of 
3ffe:ffff::/32 than anything else.

Marc.

---

From: Robert Elz <[email-masked]>
Date: Thu, 28 Jun 2001 19:32:24 +0700

Date:        Thu, 28 Jun 2001 07:48:37 -0400
    From:        Marc Blanchet <[email-masked]>
    Message-ID:  <[email-masked]>

  | but if I count the number of people that have expressed opinions on the
  | prefix to be chosen, then there is more people on the side of
  | 3ffe:ffff::/32 than anything else.

If that's what people want, then that's what they're going to get.

But before that decision is cast in stone, please everyone remember that the
Test IPv6 address Plan (which allocates 3ffe::/16 -- rfc2471) explicitly
says that all users of those addresses *will* be required to renumber.

It is a little hard to renumber addresses in printed documentation
(including RFCs).

kre

---

From: Michael Richardson <[email-masked]>
Date: Thu, 28 Jun 2001 10:46:39 -0400

Marc Blanchet writes:

>>>>> "Robert" == Robert Elz <[email-masked]> writes:
    Robert> If that's what people want, then that's what they're going to
    Robert> get.

    Robert> But before that decision is cast in stone, please everyone
    Robert> remember that the Test IPv6 address Plan (which allocates
    Robert> 3ffe::/16 -- rfc2471) explicitly says that all users of those
    Robert> addresses *will* be required to renumber.

  It says that they will be reclaimed. 
  It says that we will have to renumber.
  It says that it will not be routeable, except for testing.

  It seems to me that someone who brings up an IPv6 system in a lab
according to "IPv6 for Dummies" will have to do all of these things anyway. 

    Robert> It is a little hard to renumber addresses in printed
    Robert> documentation (including RFCs).

  The only reason to redo the documentation is if we reclaim 3ffe:ffff::/32
itself. 

  My only concern is that we have such an even /32 there. It may fail to be
properly instructive. I'd pick 3ffe:fffc::/30 or something like that.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [