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

[Robert Elz <[e-mail]>]

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

  | 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