Subject: [OPSAWG] comments on draft-weil-shared-transition-space-request-07

From: "George, Wes" <[email-masked]>
Date: Tue, 4 Oct 2011 10:54:41 -0400

I've reviewed the last two versions of this document. Generally it's in much better shape, but I have a few questions.

First, in -06, RFC1918 was listed as formally updated as I (and others) have recommended. Then in -07 that update was removed. What is the rationale for the change? The general idea I had was that RFC1918 is updated because of the address scope assumptions that you discuss in section 4.1 of -06 and in 5.1 of -07, and 5735 is updated to cover the new reservation itself.

Second, the introduction section still conflicts with itself and with section 4 regarding its instructions on usage. I think we need to make a decision one way or another on the usage - either it is only to be used for CGN (MUST) or it is not and there are additional cases to be defined in draft-bdgks (SHOULD).
Personally, I think that this document needs to stand on its own. If others wish to identify additional use cases for this space after it is defined, they are welcome to suggest them in draft-bdgks or another draft revising the guidance provided here, but I don't think it makes sense to say "use this space only for this use" and "see draft-bdgks for other uses". Perhaps simply removing the reference to bdgks will be a solution.

In section 3 alternatives - I don't see much point in the "MUST NOT number interfaces in question from squat space"
This is a SHOULD NOT if it belongs in the document at all. Squat space is being used today in quite a number of networks as a part of NAT applications. There are risks as the document notes, but MUST is too strong here, especially since this is a document allocating space for CGN, not discussing all details of the proper way to implement it. "use of squat space considered harmful" is another draft all by itself. You can make the point that this shared space allocation is preferable to squat space without needing a "must not use."

Section 4: "Service
   Providers MUST filter incoming advertisements regarding Shared CGN
   Space."
This needs to include text + a note to the RFC Editor that it also formally updates RFCxxxx (the number eventually assigned to draft-ietf-grow-no-more-unallocated-slash8s, currently in IETF LC), as it currently recommends that all route filtering be removed except for a list of the currently reserved IANA IPv4 space.
Also, typically MUST means no exceptions. If there's exceptions, the more appropriate thing would be SHOULD...Unless

Section 4/6 - "service providers MUST filter such packets on ingress" - this is too strong. This needs to be a SHOULD. Not all SPs even do ingress filtering, due to hardware limitations or other considerations.

Section 5.2 - I don't understand the subheading "empirical data" - this all seems a discussion of known issues for CGN, which is largely a rehash of the cited draft. I think that you can make the point that the proposed CGN space doesn't materially make this better or worse without the discussion of consoles, etc, by simply saying
" Based on testing documented in [I-D.donley-nat444-impacts], the CGN
   impacts on most applications that are not dependent on [application knowledge of scope or some similar qualifier] are comparable regardless of whether globally unique,
   Shared CGN Space, or [RFC1918] addresses are used.  There is,
   however, a difference between the three alternatives in the treatment
   of 6to4.
And then go on to discuss the details of 6to4 as you do in the next two paragraphs.

Nit : In the abstract I believe you mean Carrier Grade NAT or Network Address translation, rather than just "carrier grade network"

Thanks,

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Tina TSOU <[email-masked]>
Date: Wed, 05 Oct 2011 01:26:21 +0000

Hi,
In some cases, if we use
https://datatracker.ietf.org/doc/draft-tsou-pcp-natcoord/
https://datatracker.ietf.org/doc/draft-zhou-softwire-b4-nat/
https://datatracker.ietf.org/doc/draft-cui-softwire-b4-translated-ds-lite/

draft-weil-shared-transition-space-request-07 seems not absolutely necessary.

I do not oppose draft-weil, on the contrary, I support it. But some clarification text may be needed.

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of George, Wes
Sent: Tuesday, October 04, 2011 7:55 AM
To: [email-masked]
Cc: [email-masked]; Weil, Jason
Subject: [OPSAWG] comments on draft-weil-shared-transition-space-request-07

Section 4: "Service

Thanks,

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
_______________________________________________
OPSAWG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsawg

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 4 Oct 2011 21:39:38 -0400

> Sent: Tuesday, October 04, 2011 10:55 AM
> To: [email-masked]

[snip]

> 
> Second, the introduction section still conflicts with itself and with
> section 4 regarding its instructions on usage. I think we need to make
> a decision one way or another on the usage - either it is only to be
> used for CGN (MUST) or it is not and there are additional cases to be
> defined in draft-bdgks (SHOULD).
> Personally, I think that this document needs to stand on its own. If
> others wish to identify additional use cases for this space after it is
> defined, they are welcome to suggest them in draft-bdgks or another
> draft revising the guidance provided here, but I don't think it makes
> sense to say "use this space only for this use" and "see draft-bdgks
> for other uses". Perhaps simply removing the reference to bdgks will be
> a solution.
> 

IMHO, this draft stands pretty well on its own. Would the authors be averse to removing the sentence that references draft-bdgks and also removing the reference to that draft? Would this be acceptable to the larger community?

                                                           Ron

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 05 Oct 2011 15:13:43 +1300

Hi Ron,

Hmm. Back in August I said:

>>> However, I do think that *if* draft-weil-
>>> is to be published, draft-bdgks needs to be published
>>> simultaneously. Therefore, I think that synchronised Last Calls
>>> are needed.

But now, draft-weil says:

   Unlike [RFC1918] address space, Shared
   CGN Space is not available for any purpose other than numbering the
   interfaces that connect a CGN to CPE.  Additional applicability and
   analysis of Shared CGN Space is described in
   [I-D.bdgks-arin-shared-transition-space].

If the first sentence is true, it needs to use MUST NOT language. But
then, not only is draft-bdgks unnecessary as a reference, but also it is
describing practices that MUST NOT be used. In that case, draft-bdgks
needs to be completely dropped - any other result is contradictory.

    Brian

---

From: Randy Bush <[email-masked]>
Date: Wed, 05 Oct 2011 11:45:10 +0900

> Unlike [RFC1918] address space, Shared CGN Space is not available for
> any purpose other than numbering the interfaces that connect a CGN to
> CPE.

and anyone who believes that is a serious fool.  put the crap out there,
and it will be used.

randy

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 04 Oct 2011 19:59:32 -0700

> needs to be completely dropped - any other result is contradictory.
I think this is almost what I said back in August as well. Either you 
can use the space for other things (in which case Shared CGN Space *is* 
available for purposes other than numbering the interfaces that connect 
a CGN to CPE) or you cannot (in which case we most certainly won't need 
a second document describing how it is used in these other cases).

Matthew Kaufman

ps. Randy is correct anyway, in that no matter what this says (even if 
"MUST NOT"), it'll get used for the other purposes... and at this point 
there's some great suggestions of *what* other purposes over in 
braft-bdgks...

---

From: William Herrin <[email-masked]>
Date: Tue, 4 Oct 2011 23:16:37 -0400

> and anyone who believes that is a serious fool.  put the crap out there,

Hi Randy,

People will do what people will do. That generally includes anything
physically possible and a few things that no one would have believed
were possible until someone does them

The point of MUST and MUST NOT in this draft is to identify the party
at fault when something malfunctions. If packets from CGN space leak
in to or out of  my network, is it my fault for failing to filter or
is it yours? If the end-user assignment from my network collides with
the DNS resolver setting from yours, is it your fault for misusing the
space or is it just bad luck?

Regards,
Bill Herrin

-- 
William D. Herrin ................ [email-masked]  [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

---

From: Randy Bush <[email-masked]>
Date: Wed, 05 Oct 2011 12:20:43 +0900

> were possible until someone does them

the sentence is in there to pander to those who worry that this is just
another rfc 1918 extension.  as it actually *is* just another rfc 1918
extension, the sentence is not only incorrect, as it *will* be
available, but intentionally misleading.

randy

---

From: Owen DeLong <[email-masked]>
Date: Tue, 4 Oct 2011 21:10:48 -0700

I think that the categorical denial should be removed from draft-weil.

I believe that the other purposes mentioned in bdgks are useful and carefully considered
so as not t ocreate conflicts (or at least not conflicts outside of any given ISPs own actions)
and render the space more,not less, useful.

I think that the two-document approach is sound and that eliminating the second document
would cause more problems than it would solve at this point.

Owen

On Oct 4, 2011, at 7:59 PM, Matthew Kaufman wrote:

> I think this is almost what I said back in August as well. Either you can use the space for other things (in which case Shared CGN Space *is* available for purposes other than numbering the interfaces that connect a CGN to CPE) or you cannot (in which case we most certainly won't need a second document describing how it is used in these other cases).
> 
> Matthew Kaufman
> 
> ps. Randy is correct anyway, in that no matter what this says (even if "MUST NOT"), it'll get used for the other purposes... and at this point there's some great suggestions of *what* other purposes over in braft-bdgks...

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 04 Oct 2011 21:32:55 -0700

> available, but intentionally misleading.

Or we do what Owen suggests and remove that and just admit that it is 
just another RFC 1918 extension.

And then those of us opposed to another RFC 1918 extension can be 
opposed without having to fend off claims that it isn't.

Matthew Kaufman

---

From: Owen DeLong <[email-masked]>
Date: Tue, 4 Oct 2011 22:05:43 -0700

On Oct 4, 2011, at 9:32 PM, Matthew Kaufman wrote:

> Or we do what Owen suggests and remove that and just admit that it is just another RFC 1918 extension.
> 

Whoa… I'm suggesting we strike that sentence and recognize that there are
additional use cases beyond just NAT intermediate space that are applicable.
However, there is reason to partition those use cases from the intended use
cases of RFC-1918 and it is important that this address space not be used
in a manner which could conflict with the manners prescribed in draft-bdgks.

> And then those of us opposed to another RFC 1918 extension can be opposed without having to fend off claims that it isn't.
> 

It is not another RFC 1918 extension. There is a distinct need here where the
existing uses of RFC-1918 render the use of RFC-1918 space infeasible for
the application(s). This space does not need to be globally unique. The current
uses of RFC-1918 do not need to be globally unique. That is where the similarity
ends. The uses of this space are specifically cases where conflicting with existing
use of RFC-1918 space would create significant problems for the provider in
question requiring impractical if not implausible solutions (such as coordinating
customer use of RFC-1918 space so as not to conflict with ISP's use) which
would, instead, drive providers to the other less desirable solutions discussed
in draft-bdgks such as squatting or independent use of GUA.

Owen

---

From: William Herrin <[email-masked]>
Date: Wed, 5 Oct 2011 03:01:38 -0400

> available, but intentionally misleading.

Randy,

I fail to see how process supporting functional requirements for
address uniqueness amounts to "pandering."

The sentence (and many like it) is in there because Shared CGN space
has a different scope than RFC1918 within which uniqueness must be
maintained. Like with the registries for global unicast space, there
has to be a process by which facilitates maintaining uniqueness within
the defined scope.

The authors have selected "assigned by the ISP and only to CPE
interfaces" as their process. Maybe that's what it should be. Maybe it
isn't. But you're mistaken to describe it as pandering.

Regards,
Bill Herrin

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 5 Oct 2011 09:10:07 -0400

Hi Brian,

I suspect that draft-weil would be more palatable to the general community if the first sentence were true and the second sentence was dropped. This would divorce the two drafts from one another, allowing each to sink or swim on its own merits.

Do I have that right?

                      Ron

---

From: Tina TSOU <[email-masked]>
Date: Wed, 05 Oct 2011 01:21:54 +0000

Hi,
In some cases, if we use

Best Regards,
Tina TSOU

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of George, Wes
Sent: Tuesday, October 04, 2011 7:55 AM
To: [email-masked]
Cc: [email-masked]; Weil, Jason
Subject: [OPSAWG] comments on draft-weil-shared-transition-space-request-07

Section 4: "Service

Thanks,

Wes George

---

From: William Herrin <[email-masked]>
Date: Wed, 5 Oct 2011 13:04:29 -0400

> draft-weil-shared-transition-space-request-07 seems not absolutely necessary.

Hi Tina,

Thanks for the references!

One common residential Internet use case where the reuse of RFC1918
for CGNs may fail without recourse is this:

1. Home user on CGN using RFC1918 space
2. Establishes VPN to workplace
3. Workplace uses RFC1918 inside its network overlapping the CGN IP
address assignment.

For example, Home User is assigned 10.1.2.3 with a gateway of
10.1.2.1. Establishes VPN from 10.1.2.3 to 192.51.100.1 (10.1.2.3
translated to 203.0.113.4 by the CGN). VPN client assigns 192.168.1.55
and reroutes the default through the VPN. Home user then attempts to
connect to the company Intranet server at 10.1.2.3. This collides with
the 10.1.2.3 assignment on the local ethernet interface.

How does the equipment in the referenced drafts react in that scenario?

Regards,
Bill Herrin

---

From: Tina TSOU <[email-masked]>
Date: Wed, 05 Oct 2011 17:46:40 +0000

Bill,
Good question.
Would you show us a picture for precise understanding of this use case?

Best Regards,
Tina TSOU

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of William Herrin
Sent: Wednesday, October 05, 2011 10:04 AM
To: Tina TSOU
Cc: [email-masked]
Subject: Re: [OPSAWG] comments on draft-weil-shared-transition-space-request-07

Hi Tina,

Regards,
Bill Herrin

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 06 Oct 2011 09:01:18 +1300

Hi Ron,

I think that is correct. This whole proposal will *never* be palatable to
me, for reasons eloquently stated by Randy Bush. But (unlike Randy) I think
it's better for the IETF to lay down appropriate restrictions, even though
we know that ISPs will ignore them.

IMNSHO it would have been much better if the IAB had agreed that this
allocation was a policy matter to be left to IANA and the RIRs. Since
the IAB chose to define it as a technical allocation, it is the IETF that
has to take responsibility, and it is a lose-lose game for us. Whatever
we decide is wrong.

Also IMNSHO, RFC 1597 was a true disaster for the Internet. All these problems
stem from there.

Regards
   Brian

---

From: William Herrin <[email-masked]>
Date: Wed, 5 Oct 2011 18:19:04 -0400

> Would you show us a picture for precise understanding of this use case?

http://bill.herrin.us/network/cgn-example.gif

Regards,
Bill Herrin

---

From: Joel jaeggli <[email-masked]>
Date: Thu, 06 Oct 2011 21:44:11 -0700

On 10/4/11 21:10 , Owen DeLong wrote:
> I believe that the other purposes mentioned in bdgks are useful and
> carefully considered so as not to create conflicts (or at least not
> conflicts outside of any given ISPs own actions) and render the space
> more,not less, useful.
> 
> I think that the two-document approach is sound and that eliminating
> the second document would cause more problems than it would solve at
> this point.

section 2.1.2 of bdgks-03 clearly conflicts with with weil-07
requirements language, at a minimum that requires reconciliation. the
former at least recognizes applications consistent with other private
scope address ranges.

>>> Unlike [RFC1918] address space, Shared CGN Space is not available
>>> for any purpose other than numbering the interfaces that connect
>>> a CGN to CPE.  Additional applicability and analysis of Shared
>>> CGN Space is described in 
>>> If the first sentence is true, it needs to use MUST NOT language.
>>> But then, not only is draft-bdgks unnecessary as a reference, but
>>> also it is describing practices that MUST NOT be used. In that
>>> case, draft-bdgks needs to be completely dropped - any other
>>> result is contradictory.
>>> 
>>> 
>> I think this is almost what I said back in August as well. Either
>> you can use the space for other things (in which case Shared CGN
>> Space *is* available for purposes other than numbering the
>> interfaces that connect a CGN to CPE) or you cannot (in which case
>> we most certainly won't need a second document describing how it is
>> used in these other cases).
>> 
>> Matthew Kaufman
>> 
>> ps. Randy is correct anyway, in that no matter what this says (even
>> if "MUST NOT"), it'll get used for the other purposes... and at
>> this point there's some great suggestions of *what* other purposes
>> over in braft-bdgks... 
>> _______________________________________________ OPSAWG mailing
>> list [email-masked] https://www.ietf.org/mailman/listinfo/opsawg
> 
> _______________________________________________ OPSAWG mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/opsawg
>