Subject: [BEHAVE] My remark about CGN logging in today's meeting

From: Andrew Sullivan <[email-masked]>
Date: Thu, 17 Nov 2011 03:55:35 -0500

Hi,

So that I don't keep getting up and saying this at the mic, the point
that I was trying to make about the CGN stuff today was not that CGNs
are evil or wrong or whatever.

It was, rather, that if we are serious about not continuing with the
"life support" strategy that we heard about in the INT area meeting,
and if we think that the IETF should do that partly by just not
working on anything that makes life support work, then we have to
discipline ourselves not to take on work that is primarily aimed at
making life easier with transition strategies that do not lead towards
retiring IPv4.

CGNs do absolutely nothing in the direction of encouraging moving to
IPv6, nor in the discouragement of IPv4.  Making the logging problems
of running CGNs less severe is, therefore, not going to discourage
IPv4 nor promote IPv6.  Offering advice for how to deploy CGNs does
not discourage their deployment.

I don't know whether I think the strategy of "Just say no" will work.
That was, after all, the original answer to doing NAT at all, and it
didn't work.  Certainly the DNS community has been trying to say no
for years, and that has been a massive failure.  But if we're actually
going to adopt a "Just say no" strategy, then some of the CGN drafts
are the sorts of things that will have to be rejected, and I therefore
don't think they should become WG items at least until we have decided
whether the "No" strategy is a good idea.  Otherwise, we'll be
declaring that we think we should not stop work on the life support
strategies.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 17 Nov 2011 11:16:42 +0100

Andrew, I completely agree with you. 

Being consistent is just fair. It is not OK to suggest to discontinue other people's work but than in the next second to suggest new work that is in contradiction. 

For example, in the Intarea meeting Dan Wing argued that we have to provide "life support" to deal with the issues caused by address sharing due to CGNs by working on draft-boucadair-intarea-nat-reveal-analysis-04. Then, a few minutes later he gives a presentation and argues to discontinue work that focuses on life support.

Ciao
Hannes

On Nov 17, 2011, at 9:55 AM, Andrew Sullivan wrote:

> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 17 Nov 2011 06:27:41 -0800

> Andrew, I completely agree with you.

I also agree. But I think we are on the wrong list.  I may be wrong, but
imho it is softwire that is in overdrive.

I would love to say that 6rd, dslite, and Nat64/DNS64 are the menu, now go
deploy. Any rough edges in any of these have a clear long term solution, do
more v6.

Cb

> Being consistent is just fair. It is not OK to suggest to discontinue
other people's work but than in the next second to suggest new work that is
in contradiction.
>
> For example, in the Intarea meeting Dan Wing argued that we have to
provide "life support" to deal with the issues caused by address sharing
due to CGNs by working on draft-boucadair-intarea-nat-reveal-analysis-04.
Then, a few minutes later he gives a presentation and argues to discontinue
work that focuses on life support.

---

From: Nejc Škoberne <[email-masked]>
Date: Fri, 18 Nov 2011 02:46:10 +0800

Hi,

> making life easier with transition strategies that do not lead towards

I strongly agree. I think that IETF should not be the place to work on 
IPv4 "life support" strategies (any more). I felt that yesterday at intarea
there was (at least) a "rough consensus" for this direction by most of
the people there. Also, I think that if there really is such a consensus,
that it would make sense for IETF to make an "official" stand on this
(if there isn't one yet and if that's even possible).

> not discourage their deployment.

Here, I partly disagree. IMHO, CGN in general stands for "the NAT function
is located in the ISP network". NAT64 and DS-Lite are also examples of
CGN technologies, yet they are encouraging moving to IPv6 at least
to some extent (DS-Lite in the access network, NAT64 in the end-user
network). So I think there are significant differences among various CGN
technologies. It is quite simple, I think. Those, which in any way
contribute to making IPv4-only life easier, should not be considered
anymore (at least not in the IETF). If we want people to start working
harder on IPv6, we have to let IPv4-only life be as hard as it is.
Anyway, people will do whatever they please in the end. All IETF can do
to push things in the right (IPv6) direction is not to work on things,
which deviate from this direction (IPv4-only(-allowing)).

> declaring that we think we should not stop work on the life support

I agree.

Regards,
Nejc

---

From: Nejc Škoberne <[email-masked]>
Date: Fri, 18 Nov 2011 02:55:05 +0800

Hi,

> imho it is softwire that is in overdrive.

SD-NAT was (also) presented at BEHAVE today at IETF 82. It makes IPv4-only
CGNs' lives easier by providing statelessness for them. I know, the
authors say it is "mechanism-agnostic". Well, if it is, then it should be made
"mechanism gnostic" and allow for IPv6 transition mechanisms only.

Nejc

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 18 Nov 2011 10:04:04 +0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Hannes Tschofenig
> Sent: Thursday, November 17, 2011 6:17 PM
> To: Andrew Sullivan
> Cc: [email-masked]
> Subject: Re: [BEHAVE] My remark about CGN logging in today's meeting
> 
> other people's work but than in the next second to suggest new work
> that is in contradiction.
> 
> provide "life support" to deal with the issues caused by address
> sharing due to CGNs by working on draft-boucadair-intarea-nat-reveal-
> analysis-04.

draft-boucadair-intarea-nat-reveal-analysis is necessary to distinguish
between good guys and bad guys with any address sharing, including 
NAT64, 4rd, dIVI, A+P, and others.  Such address sharing will be 
necessary so long as there are IPv4 servers on the Internet.

The problem only goes away when the Good Guys (legitimate users)
are running IPv6 and the servers they are accessing support IPv6.
The attackers will use address sharing if address sharing 
gives them an attack advantage.  
draft-boucadair-intarea-nat-reveal-analysis shows mechanisms to
eliminate this attack advantage.

-d

> Then, a few minutes later he gives a presentation and
> argues to discontinue work that focuses on life support.
> 
> Ciao
> Hannes
>