Subject: [BEHAVE] draft-sivakumar-behave-edm-harmful comments

From: Cameron Byrne <[email-masked]>
Date: Sat, 10 Mar 2012 05:50:39 -0800

Citing some RIR policy

http://www.apnic.net/community/ipv4-exhaustion/exhaustion-and-network-operators

http://www.ripe.net/ripe/docs/ripe-530#----use-of-last-/8-for-pa-allocations

The 2 above policies, already in force in APNIC and soon to be in
force in RIPE, say a new entrant can only get a /22, 1,024 IPv4
addresses

Trying to keep the math simple here, 64,000 available ports * 1024
IPv4 addresses = 65.5 million sessions.  Just as one data point, i
cannot run my network on this allocation, assuming i put 100% of the
allocation to CGN use.

This brings me to my questions about the draft, it states:

"While it is tempting to maximize the return on the investment by
   maximizing the use of the existing IPv4 addresses, doing End point
   dependent mapping, the harmful effects of this overrides any benefits
   that it offers."

Can this be quantified?  It sounds a bit hand wavy to me.  Especially
since you are essentially saying that there is NO business case for
any new entrant to enter the IPv4 large service provider space, since
EIM is required and IPv4 allocations to support EIM are not available
at large scale.   Does this make sense

Next

"Peer to Peer applications are becoming very common and some real life
   examples of P2P applications are SIP used by VoIP service providers,
   instant messaging, voice and video chat, Google Talk, Apple Facetime
   and several famous gaming applications.  The notion of not supporting
   P2P applications is not just practical and NATs MUST be designed to
   facilitate these applications."

You are equating things that are not equals. Correct, some variations
of SIP do not work without ALGs in EDM NATs.  But, ALGs do make some
protocols work, like some types of SIP (there are too many types of
SIP to make broad statements).  Separately, it is my experience that
various video chat applications like Google Talk work across EDM NATs
without ALGs, ...same with Skype and other so called p2p applications.

So, you may want to change the language above to be more specific
about what exactly breaks and why... and avoid painting with a broad
brush .... and avoid listing applications that DO work with EDM like
Google Talk (yes, relays are used... but the important thing is the
service works for the customer)

Overall, i am opposed to this draft saying EDM is harmful, you are
better off saying IPv4 exhaustion is harmful.  EDM is quite common
today.  Saying EDM is bad is not helpful, but a technical discussion
about pros and cons of EIM and EDM would be helpful.  There will be
more pressure to use EDM as IPv4 exhaustion intensifies.

CB

---

From: ssenthil <[email-masked]>
Date: Mon, 12 Mar 2012 11:11:49 -0500

Thanks for your comments, please see inline.

> Citing some RIR policy
http://www.apnic.net/community/ipv4-exhaustion/exhaustion-and-network-operator>
s
> at large scale.   Does this make sense

I am not sure what do you mean by quantifying here, quantifying the number
of applications that would break? The business case has always been there,
not just today and there are several NAT implementations that does this.
But that did not deter IETF from making the statement in RFC4787 to say that
it should not be used.

> service works for the customer)

So you would like to see specific examples on what apps break and why,
as opposed to listing all the P2P apps? I can collect some specifics and add
it to the draft. If you use relays in between that is not truly P2P, same
thing with ALGs.

> Overall, i am opposed to this draft saying EDM is harmful, you are

RFC 4787 has already said dependent mappings are bad and should not be used,
but it doesn't go into the details on why it is bad. That is the intention
of this draft. 

> more pressure to use EDM as IPv4 exhaustion intensifies.
IETF has taken a position to discourage any techniques that would prolong
the life of IPv4 and EDM does exactly that and in the process breaks apps.

Senthil

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

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 12 Mar 2012 09:33:47 -0700

Hi,

In line.

> But that did not deter IETF from making the statement in RFC4787 to say that

You said in the draft that EDM's negative characteristics exceed the
positive attributes of maximizing address use with EDM and port
overloading.  Thus, everyone should use EIM.

I said in my email, it is not possible to run a large network on a /22
with EIM, and a /22 is all that a new entrant may get from an RIR per
policy today in APNIC and soon in RIPE.  I think ARIN has a similar
plan, but i have not seen it.

Thus, i do not think it is beneficial for the IETF to say EDM and port
overloading are harmful or that EIM is a better "return on
investment",   when it may be the only way to provide IPv4 service for
new entrants.   My stance is that your assertion is wrong, the ability
to compete and offer commercial service using EDM is superior than not
offering service at all.  Thus, EDM exceeds that value of EIM (not
offering service).  Saying EDM is harmful is negative statement to
network operators that use it today (many do) and explicitly hurts new
entrants that must use EDM and port overloading to offer legacy IPv4
service.

Saying EDM is harmful and publishing in the IETF does not achieve
anything in the real world, the only thing it does is confuse people
who read and think EDM is an obviously unjustified path (the IETF said
so ...) and design protocols and applications that assume EDM is not
there, when it fact it is.  And, my guess is that EDM use will
increase given the constraints on IPv4 space.

Your time is better spent writing a draft on how applications can
better work in an EDM network, since that is the direction the
internet is going (more ipv4 constraints)

> it to the draft. If you use relays in between that is not truly P2P, same

Right, explain to me why this draft is needed?  Explain which
applications break on an EDM network that do not break on an EIM
network.

P2P is an overloaded term, and therefore does not mean anything in
this technical context. Saying pure P2P does not work in an EDM
network may be correct, but saying Google Talk or Skype or BitTorrent
does not work on an EDM network is wrong.  They do work.

> the life of IPv4 and EDM does exactly that and in the process breaks apps.

Great. The IETF made another short sighted declaration to justify the
use of tools like STUN.  That promulgation by the IETF in RFC4786 was
rejected by hardware/software implementors and network operators who
made EDM gear and deployed it.  So, now you want the IETF to say EDM
is bad again, now that there is even less evidence or motivation that
the suggestion will be listened to?

I am all for highlighting the technical ins and outs so everyone
understand the operations of various network functions, but "harmful"
drafts are like lightening rods.   Especially when all the available
evidence shows that, on the real internet, EDM is helpful to network
operators... and they are the ones that buy and deploy CGNs.

CB

---

From: Simon Perreault <[email-masked]>
Date: Mon, 12 Mar 2012 13:47:20 -0400

One aspect of EDM that may have an impact on large operators is logging.

(Assuming you need to log...)

With EIM you only need to log internal<->external port mappings. If 
allocation is done semi-statically or in port blocks then this is fairly 
efficient.

With EDM you need to log every single connection. And for every single 
connection you additionally need to log the destination address and port 
(this is not necessary with EIM). So we're talking about a *lot* more 
data to be logged.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 12 Mar 2012 10:56:11 -0700

On Mon, Mar 12, 2012 at 10:47 AM, Simon Perreault
<[email-masked]> wrote:
> (this is not necessary with EIM). So we're talking about a *lot* more data
> to be logged.
>

That is closer to a quantification, but still far from justification
as "harmfull"

EIM is a lot more logging than stateless, but no need to say EIM is harmful.

In any case, there are tradeoffs.  I assume the harmful title means
that with X there is no way the tradeoffs make sense or that X is
fundamentally flawed.

I don't believe that case has been made here.

CB

---

From: Simon Perreault <[email-masked]>
Date: Mon, 12 Mar 2012 14:20:49 -0400

> That is closer to a quantification, but still far from justification

I'm not trying to justify the "harmful" qualifier, I'm trying to expose 
a disadvantage of EDM to which you might be sensitive.

In any case, the "harmful" qualifier would be derived from the harm EDM 
causes to the Internet, not to some ISPs' operations department.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Mon, 12 Mar 2012 15:55:49 -0400

> One aspect of EDM that may have an impact on large operators is logging.

Correction: this is an aspect of EDM *with port overloading*. Not all 
EDM NATs do port overloading, so we have to be precise.

Simon

---

From: Olivier Vautrin <[email-masked]>
Date: Mon, 12 Mar 2012 13:33:19 -0700

It is possible to mix EIM and EDM on the same CGN. You can have EDM for
HTTP and DNS request and EIM for the rest for example. So I don't think
the general comment "EDM breaks application" is true as you can activate
it only on applications that doesn't break.

/Olivier

---

From: ssenthil <[email-masked]>
Date: Mon, 12 Mar 2012 17:30:20 -0500

Pls see inline.

<snip>
> entrants that must use EDM and port overloading to offer legacy IPv4

Good, but you don't indicate how many customers called in to say that their
apps do not work, or how many hours was spent or how many dollars were spent
by the customer service in answering those calls.

On the other hand, I can tell you that many of the customers that I interact
with has been banging us for getting the EIM and EIF in the last couple of
years. To keep the balance I have also heard people asking us to do port
overloading lately but that is far less than the other. I know a lot of our
enterprise customers have EDM deployments in their networks (no port
overloading though) for many years, with handful of ALGs. But the landscape
is different when I talk to the SP customers as they don't have the control
on what apps can be used and supported.

> internet is going (more ipv4 constraints)

I don't really agree that the direction is going to be NATs with EDMs.
Maybe I should ask you how many operators that you know deploy and embrace
EDM successfully? My experience suggests the opposite.

<snip> 
> the suggestion will be listened to?

You are making an assumption that EDM is widely deployed, I don't see any
evidence of that. 

> operators... and they are the ones that buy and deploy CGNs.

I am more interested in documenting the applications that break with EDMs
that will cause more ALGs to be developed and less apps to be developed.
EDM cannot work with the MAP and PCP, which assumes that port overloading is
not used. I will focus more on the specifics of what applications will break
and why.

Thanks for your comments.
Senthil

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 12 Mar 2012 14:50:05 -0700

> on what apps can be used and supported.

So what you are saying is that there is no consensus, and that
different networks want / need / have different things.

Thus, you have no basis for a "harmful" draft.

> EDM successfully? My experience suggests the opposite.

My guess is that most major mobile providers are this way.  Since
those deployed CGN platforms are usually based on firewalls, i expect
EDM behavior unless shown otherwise.

> You are making an assumption that EDM is widely deployed, I don't see any

I believe EDM is more widely deployed than EIM.  If you have data to
show otherwise, please show it.

> that will cause more ALGs to be developed and less apps to be developed.

Great. Do that.  So far, you have not documented any applications that
break with EDM, AFAIK.

> not used. I will focus more on the specifics of what applications will break

MAP and PCP also do not exist on the real internet.  In fact, they are
just drafts and not published standards, AFAIK.

CB

---

From: ssenthil <[email-masked]>
Date: Mon, 12 Mar 2012 18:28:38 -0500

> Thus, you have no basis for a "harmful" draft.
Consensus for writing a draft from all the network operators? I don't know
where you got that idea that for one to "write" a draft there should be
consensus. Regarding your statement on the basis for that draft, that is
your subjective opinion and you are entitled to yours just like I am
entitled to mine.

> EDM behavior unless shown otherwise.
Your guess? 

> show otherwise, please show it.

I believe otherwise.
> Great. Do that.  So far, you have not documented any applications that
I will.

---

From: Olivier Vautrin <[email-masked]>
Date: Mon, 12 Mar 2012 15:52:48 -0700

You could use EIM only for the ports used for PCP. That way normal traffic
(not using PCP), would use EDM/Overloading.

The IETF is already advising the use of EIM with RFC4787, which is good.
But EDM is not "harmful" in a generic way. It is harmful if badly used,
which is the case of most technologies. There are cases where
EDM/Overloading is needed.

I do think that a draft listing all the issues with EDM would be useful
though.

/Olivier

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 12 Mar 2012 16:01:20 -0700

<snip>
>> EDM behavior unless shown otherwise.

I will be humble and say yes, a guess.

A little bit of Googling resulted in this public info , not a
definitive data source, but it is one data point

http://www.juniper.net/us/en/local/pdf/implementation-guides/8010076-en.pdf

Page 18

"Although EIM is a supported feature and requested by many customers,
it is not widely used at this point because
applications have grown to be able to traverse NAT and receive inbound
connections over the same outbound connection.
Also, applications that need ALGs are still prevalent.
If EIM is needed, it should be on a per application basis. In other
words, only enable EIM for the applications that need it"

CB

---

From: Olivier Vautrin <[email-masked]>
Date: Mon, 12 Mar 2012 16:04:45 -0700

I agree with Cameron. It is difficult to have the full view of what is
deployed but my opinion is that EDM is more widely deployed than EIM today
in mobile environment. It will probably change though with RFC4787 but it
will take time.

/Olivier

---

From: <[email-masked]>
Date: Fri, 16 Mar 2012 15:27:59 +0100

Dear Cameron, Senthil,

For the point discussed below, I recommend you to read this interesting paper (in particular Table 3) 

http://research.microsoft.com/en-us/people/mzh/netpiculet.pdf.

(I cc Zhiyung who can provide you more information if needed)

Cheers,
Med 

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] 
>De la part de Cameron Byrne
>Envoyé : lundi 12 mars 2012 22:50
>À : ssenthil
>Cc : [email-masked]
>Objet : Re: [BEHAVE] draft-sivakumar-behave-edm-harmful comments
>

---

From: Joel jaeggli <[email-masked]>
Date: Sun, 18 Mar 2012 08:58:02 -0700

I'm not sure what to think if this draft.

The way I read it some load balancer deployments that I currently have
are considered harmful. that may well be but they meet my needs so
there's a question of scope. not all edm devices sit between isp
customers and the internet.

On 3/10/12 05:50 , Cameron Byrne wrote:
...

> cannot run my network on this allocation, assuming i put 100% of the

If I don't have enough IPs to meet the requirement for a non-edm mapping
while fulfilling my other addressing needs with available resources I'm
going to overload, no matter what the draft says. If we would like to
provide advice that should be soundly ignored when necessary I'm not
sure what the value of the advice is.