Subject: Re: Last Call: <draft-weil-shared-transition-space-request-14.txt> (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP

From: "C. M. Heard" <[email-masked]>
Date: Wed, 1 Feb 2012 13:25:33 -0800 (PST)

On Wed, 1 Feb 2012, Brian E Carpenter wrote:
> On 2012-02-01 08:14, Pete Resnick wrote:
> > On 1/31/12 11:59 AM, George, Wes wrote:
> >>> From: Noel Chiappa [mailto:[email-masked]]
> >>>
> >>> Is that wise? I thought (IIRC, and maybe I'm spacing) the 
> >>> whole reason for allocating this space was that 1918 space 
> >>> _couldn't_ easily be used for CGN because there were too many 
> >>> conflicting usages.
> >>>      
> >> [WEG] yes, but the general sense I got from the ensuing discussion was
> >> that no one expects anyone to actually adhere to that advice (ie MUST
> >> NOT be used as substitute for 1918 space), and as soon as the space is
> >> released, it'll be "cats and dogs living together, mass hysteria..."
> >> because everyone and their cousin will start using it as 1918-bis
> >> anyway, no matter whether the IETF wags their fingers at them or not.
> 
> I have no doubt that this space will be (mis)used as additional
> private ambiguous address space. But IMHO the text should make it
> clear that this is the wrong way to use it and give the reasons
> why - basically the same information as in the new text, but stated
> exactly the other way round. For example
> 
>      Shared Address Space is IPv4 address space designated for Service
>      Provider use with the purpose of facilitating CGN deployment.
>      Shared Address Space is not intended to be used as additional [RFC1918]
>      space, because either or both of the following issues might arise:
> 
>      o  Shared Address Space could also be used on the Service Provider side
>         of the CPE, with overlapping subnet or host addresses.
> 
>      o  Some CPE routers behave incorrectly when using the same address block on
>         both the internal and external interfaces.
> 
> > Speaking as one of the bozos^h^h^h^h^h ADs whose comments (and suggested
> > text) ended the document up here, let me suggest the slightly less
> > pessimistic view from Wes's, and the reason that I think this
> > *shouldn't* specifically update 1918:
> > 
> > This *is* a special use address block that is akin to 1918. It is
> > non-routable address space, just like 1918. But unlike 1918, this block
> > is defined as "might be used by your ISP on your outside interface". So,
> > people using it inside their networks (which, I agree with Wes, will
> > happen, and like everything else on the net, will be done stupidly by
> > some) have been told that this is *not* private use space and that they
> > use it at their own risk and their CGN service might stop working if
> > they use it in a way not described in this document. But I'd hate for us
> > to allocate space to "CGNs only" when it's obvious that this can be used
> > for a whole class of these sorts of things, and can be used by other
> > people who build sane equipment that understands "shared" addresses can
> > appear on two different interfaces. These aren't "private" addresses a
> > la 1918, they're "shared", so it's not an addition to that space. Let's
> > properly document what it is we're doing, giving people fair warnings.
> 
> Exactly, hence my suggested text above.

+1

//cmh

---

From: Pete Resnick <[email-masked]>
Date: Wed, 1 Feb 2012 16:33:43 -0600

On 1/31/12 1:38 PM, Brian E Carpenter wrote:
> IMHO the text should make it

Ah. I think we're in pretty good agreement. The -14 text uses the words 
"may be used as [RFC1918] private address space", and I agree with you 
that we don't want to use those words. We need to say that though it is 
similar to 1918 space, it has limitations. So I wouldn't object to the 
above text , but I think we do have to give some indication of the flip 
side. I want something that says that Shared Address Space can be used 
for other Service-Provider-type uses and are not limited to CGNs. They 
can be used on any network equipment willing to do address translation 
across interfaces which both use the Shared Address Space, just as CGNs 
do. That is, clarify throughout that this *isn't* just like 1918 space 
(it has limitations and can only be used in particular circumstances), 
but do describe what the conditions are under which it can be used.

In your above, I would even strengthen "is not intended to be used as 
additional [RFC1918] space" to "can not be use as [RFC1918] private 
address space", and then maybe add something about where it can be used. 
In the intro, I would change the second paragraph (and it's sub-bullets) to:

    Shared Address Space is similar to [RFC1918] private address space in
    that it is not global routeable address space and can be used by
    multiple pieces of equipment. However, Shared Address Space has
    limitations in its use that the current [RFC1918] private address
    space does not have. In particular, Shared Address Space can only be
    used on routing equipment that is able to do address translation
    across router interfaces when the addresses are identical on two
    different interfaces.

Or something to that effect. Does that still capture that Shared Address 
Space is similar to 1918 space, it can be used for purposes other than 
CGN, but it can't be used everywhere 1918 addresses are used?

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 02 Feb 2012 14:40:30 +1300

Pete,

We seem to be agreeing violently.

Regards
   Brian Carpenter

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 11 Feb 2012 09:38:01 +0900

Pete Resnick wrote:

> and can be used by other 
> appear on two different interfaces.

With so complicated functionality of NAT today, the only
practical approach to build such equipment is to make it
a double NAT as:

                          +-----+   +-----+
	(a private space)-| NAT |---| NAT |-(same private space)
                          +-----+   +-----+

the only problem is that we need another private address
space used only between element NATs within the double NAT.

Can IETF allocate such address?

						Masataka Ohta

---

From: Pete Resnick <[email-masked]>
Date: Fri, 10 Feb 2012 21:37:14 -0600

On 2/10/12 6:38 PM, Masataka Ohta wrote:
> a double NAT

Correct. That's what a CGN is, and that is what other equipment of this 
sort would be.

> as:

That's what this document is doing: Allocating address space to go 
between 2 NATs.

Maybe I don't understand your question?

pr

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 11 Feb 2012 16:35:25 +0900

Pete Resnick wrote:

> Correct.

Note that the double NAT, here, is AN equipment.

> Maybe I don't understand your question?

My point is that those who are arguing against the proposed
allocation because of the capability of a double NAT
equipment should argue for allocation of another space
to enable development of the double NAT equipment.

						Masataka Ohta