Subject: Re: Consensus Call (Update): draft-weil-shared-transition-space-request

From: [email-masked] (Noel Chiappa)
Date: Wed, 7 Dec 2011 19:57:54 -0500 (EST)

> From: Mark Andrews <[email-masked]>

    > And it needs a seperate I-D which indicates how equipement can signal
    > that it supports 240.0/10. Returning such a address to equipment that
    > is not prepared to receive is a *very* bad idea.

I wasn't suggesting using general use for 240/ addresses, as endpoint names -
that's a hopeless cause, there are too many things out there that can't deal
with them. Who wants an address lots of people can't talk to (with, or
without, a mechanism to discover explicitly that they can't talk to it)?

I was suggesting them purely for infrastucture use, in (probably _very_
limited) usage domains where their visibility would be over a limited scope,
one where all devices can be 'pre-cleared' for using them.

	Noel

---

From: Benson Schliesser <[email-masked]>
Date: Wed, 7 Dec 2011 19:36:52 -0600

> one where all devices can be 'pre-cleared' for using them.

I agree that this is an optimal scenario for near-term deployment of 240/4, and that we should pursue the conversion of class E to unicast.

However, it could be compared to using RFC1918 space for such a purpose. For instance http://tools.ietf.org/html/draft-kirkham-private-ip-sp-cores discusses some of the potential issues of using RFC1918 for infrastructure links. I'd guess that 240/4 has similar issues, and perhaps additional issues that we haven't considered.

Cheers,
-Benson

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 08 Dec 2011 12:37:31 +0900

> one where all devices can be 'pre-cleared' for using them.

More generally, class E should be used for unicast only when
operators are statically, without dynamic investigation, sure
that all the equipments support class E.

						Masataka Ohta