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

[Marc Blanchet <[e-mail]>]

At/À 01:53 2001-06-28 +0700, Robert Elz you wrote/vous écriviez:
>     Date:        Wed, 27 Jun 2001 11:00:20 -0700
>     From:        Alain Durand <[e-mail]>
>     Message-ID:  <5.1.0.14.0.20010627104811.00b0bfa0@jurassic>
>

...

>   | 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)

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.

>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.

>   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).

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


>   | 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, ...

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.


>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