Subject: Re: [rrg] solution strategies, nat?

From: RJ Atkinson <[email-masked]>
Date: Thu, 01 Jan 2009 08:49:33 -0500

On  31 Dec 2008, at 20:15, William Herrin wrote:
> I would like to hear about additional NAT-based techniques which, like
> Chris' notion, suggest a credible plan for reducing the demand for
> core routing slots compared to the status quo.

I cited "NAT66" specifically.  I also noted both where that
discussion has been happening (although some related
discussion has also happened here) and the existence of an I-D.
For example, one form of NAT66 is stateless, meaning that
sessions could be initiated from outside or inside the NAT
perimeter.  Please go read the draft.

I also specifically cited "architected NAT", where there is
a concrete specification that has particular properties.

Thirdly, I've talked in the past about how Locator rewriting
(which is a kind of NAT) could be used with ILNP.  This is a bit
similar to Six/One, but is not identical.  This is discussed
in detail in various published papers.

Either of these is rather different from your apparent view
of a single monolithic "IPv4 NAT".  In fact, a wide range of
different forms of NAT exist, most of which are not very well
documented.  Different NAT techniques/implementations have
different properties.

> I would prefer not to hear about the usefulness of vanilla NAT.

Certainly, it is your choice what you choose to read or hear.

> We have determined beyond the shadow of a doubt
> that the status quo is not, at this time, self-reducing.

The RG has *not* made a determination that all existing NAT
techniques (there are a wide range of various NAT methods
available in myriad different implementations) aren't part
of the possible solution set.

Under IRTF process rules, only the RG Chairs have the authority
to make a consensus determination.

> Vanilla NAT is indeed useful, but as
> widely deployed today it is already a part of the status quo.

Since IPv4 NAT has so many different forms, with varying
properties, I have no idea what you mean when you say
"Vanilla NAT".

Yours,

Ran
[email-masked]

_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: "William Herrin" <[email-masked]>
Date: Thu, 1 Jan 2009 11:37:36 -0500

Ran,

Please understand, I am neither for nor against the use of NAT as a
route reduction technique. I do, however, insist on me being able to
satisfactorily explain how a particular approach would reduce the need
or demand for core routing slots. Until someone, such as yourself, has
explained that to me well enough that I can explain it to someone
else, it isn't gong in the document.

On Thu, Jan 1, 2009 at 8:49 AM, RJ Atkinson <[email-masked]> wrote:
> I cited "NAT66" specifically.

It is not immediately obvious to me how any form of NAT66 reduces the
demand for core routing slots. If it's obvious to you, I'm listening.

> a concrete specification that has particular properties.

Would you suggest a reference which describes "architected NAT"? The
first 20 hits on google led to offhand comments which were
unrevealing.

> in detail in various published papers.

Link please?

> to make a consensus determination.

That is an... interesting... refutation of established fact.

Regards,
Bill Herrin

-- 
William D. Herrin ................ [email-masked]  [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 02 Jan 2009 08:43:35 +1300

> else, it isn't gong in the document.

Slide 15 in
http://www.cs.auckland.ac.nz/~brian/RRG0708.pdf

    Brian

---

From: Scott Brim <[email-masked]>
Date: Thu, 1 Jan 2009 15:59:59 -0500

Excerpts from RJ Atkinson on Wed, Dec 31, 2008 02:37:07PM -0500:
> (NAT/NAPT or LocatorRewriting or pick a another name) performed
> inside a site's border router can enable a site to multi-home
> effectively without any de-aggregation (i.e. without any impact on
> the DFZ RIB or DFZ FIB).  Existing mechanisms that enable
> distributed firewalls to share session state would clearly also work
> to share NAT session state among a set of site border routers, if
> that were desired.

Multihoming on different providers?  If an endpoint appears to have
two different addresses due to being NATted onto two different
providers, and routing changes so that packets switch from flowing
through one provider to flowing through the other one, connections
break.

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 01 Jan 2009 16:24:08 -0500

On  1 Jan 2009, William Herrin wrote:
> It is not immediately obvious to me how any form of NAT66 reduces
> the demand for core routing slots. If it's obvious to you, I'm  
> listening.

draft-mrw-behave-nat66-01.txt

NAT66 is one example of an Architected NAT.  Kindly note that
NAT66 still seems to be a work in progress, and hence might change,
although it seems very well written to me at present.

One can imagine other instances of an Architected NAT that might make
different design decisions and might target either IPv4 or both
IPv4 and IPv6.  (NAT66 is an IPv6-specific approach.)  [See also
other comments later in this note.]

(Depending upon perspective, some might consider SHIM6
another example of an "Architected NAT", albeit one where
the NAT function occurs inside the end system.)

Some other RG folks have suggested that NAT is a viable approach
for the group to consider:
	<http://www.irtf.org/pipermail/rrg/2008-October/000009.html>
	<http://www.irtf.org/pipermail/rrg/2008-October/000075.html>
	<http://www.irtf.org/pipermail/rrg/2008-December/000614.html>

Of the last URL's concerns, NAT66 appears not to have the issues
mentioned with "N:1 multiplexing" or the issues of "session
survivability in the case of uplink failover", at least in some
modes of operation.  (NAT66 defines several options.)

Also, as noted earlier today by Brian Carpenter:
	http://www.cs.auckland.ac.nz/~brian/RRG0708.pdf

> Link please?

draft-rja-ilnp-intro-02.txt contains a number of references.

Separately, also today, Scott Brim commented:
% If an endpoint appears to have two different addresses due to
% being NATted onto two different providers, and routing changes
% so that packets switch from flowing through one provider to
% flowing through the other one, connections break.

In an old IPv4 NAT, particularly those in low-cost consumer
devices, the above is commonly true.

With NAT66, if both sites are using NAT66 and both are using
it in "Algorithmic Translation" (Section 5.1.1) mode, it is
not obvious that this issue [1] still exists.  The transport-layer
state can use, for example, ULA addresses (which are NOT in the
DFZ RIB/FIB) and the algorithmic mapping means no NAT session state
is required either.

I'm neither particularly advocating NAT-based approaches,
nor am I particularly opposed to NAT-based approaches.  I
would prefer that the RG examine all of the options, and
this sort of an approach seems to be a viable option.

Cheers,

Ran
[email-masked]

[1] I.e. the issue created by using different addresses,
with different ISP-aggregatable routing prefixes, on
the wire between sites, for a single session.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 02 Jan 2009 11:46:59 +1300

> through one provider to flowing through the other one, connections

Certainly. So if you were product manager for a highly reliable
distributed application, I'm sure you would insist that it was
coded to detect permanent transport failures and try alternative
addresses. That may not be elegant computer science but it's one
way that the Internet routes around damage.

    Brian

---

From: "Tony Li" <[email-masked]>
Date: Thu, 1 Jan 2009 16:39:13 -0800

|Certainly. So if you were product manager for a highly reliable
|distributed application, I'm sure you would insist that it was
|coded to detect permanent transport failures and try alternative
|addresses. That may not be elegant computer science but it's one
|way that the Internet routes around damage.

And that again results in trying to fix the routing architecture at layers 7
and 8.  You'll pardon me if I don't find that a particularly satisfying
'solution'.

Tony

---

From: "Tony Li" <[email-masked]>
Date: Thu, 1 Jan 2009 17:06:55 -0800

Hi all,

|>> We have determined beyond the shadow of a doubt
|>> that the status quo is not, at this time, self-reducing.
|>
|> Under IRTF process rules, only the RG Chairs have the authority
|> to make a consensus determination.
|
|That is an... interesting... refutation of established fact.

<co-chair>

I'm unaware of what established facts those might be.  Let me set forth the
facts as I know them:

The IRTF operates under the procedures documented in RFC 2014, and under the
direction of the IRTF Chair.  Most significantly, we have been instructed by
the IRTF Chair to operate openly.  Within the bounds of those restrictions,
the RRG Chairs are free to set their own process, and we have many times
reiterated that we choose to operate under the "rough consensus" process
that the IETF normally uses.  We have selected this process specifically
because we feel that without the buy in of the majority of the stakeholders,
any architectural recommendation that we might make would be simply so much
hot air.  Note that this is a decision that is wholly local to the RRG and
other IRTF RGs may have a variety of different processes.

Per the "rough consensus" approach, as documented in RFC 2418, it is the
responsibility of the Chairs to determine if we have reached rough
consensus.  See section 3.3 of RFC 2418.

That said, please note that that does NOT mean that Bill is out-of-bounds in
conducting his own, unofficial consensus checks, nor is he out-of-bounds in
holding his own opinion of what the consensus is, nor in opining about what
that consensus is.  Those are simply unofficial opinions and do not
represent the official consensus of the RRG.  

Please also note that the RRG co-chairs reserve the right to change the
official processes of the RG in the future, as needs arise.

I hope this clarifies any process questions.

</co-chair>

Happy Gregorian New Year,
Tony

---

From: Robin Whittle <[email-masked]>
Date: Fri, 02 Jan 2009 12:55:39 +1100

Tony Li wrote:

> And that again results in trying to fix the routing architecture at
> layers 7 and 8.  You'll pardon me if I don't find that a
> particularly satisfying 'solution'.

I agree.  Furthermore, it would be in violation of Herrin's
Architectural Principle:

   http://www.irtf.org/pipermail/rrg/2008-December/000620.html

     Any problem can be solved at the application layer for a single
     application. Architectural solutions solve the problem at a
     lower layer so that it stays solved for *all* applications.

This is a concise statement of good design principles which have long
been known in many fields - including networking, software, building
design and urban planning.

  - Robin

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 02 Jan 2009 15:13:02 +1300

> and 8.  You'll pardon me if I don't find that a particularly satisfying

It isn't, which is why we're here, I think.

To be clear what I'm thinking, it seems that if nothing new comes out
of the routing world, we'll eventually hit the wall where PI-style
multihoming cannot grow. Then economics will rule it out except for
very large customers. At that point, medium or small customers who want
multihoming will either have to use standard multi-prefix PA IPv6, or
NAT66 (assuming IPv4 addresses are exhausted by then). In both cases,
non-SCTP transport sessions will break when multihoming fails over.
The applications community will resolve that either by supporting
address failover at layer 7 or by converting to SCTP (or some
other agile transport).

    Brian

---

From: "Tony Li" <[email-masked]>
Date: Thu, 1 Jan 2009 19:42:49 -0800

|To be clear what I'm thinking, it seems that if nothing new comes out
|of the routing world, we'll eventually hit the wall where PI-style
|multihoming cannot grow. Then economics will rule it out except for
|very large customers. 

Or, in another form, the cost per global prefix will grow (in constant
dollars).  One alternative at this point is that folks simply stop accepting
global prefixes, but given that the incentives of the carriers are clearly
slanted towards accepting everything, it's more likely that prefixes are
accepted, despite increased costs.  Given the current economic model, that
implies that the cost basis for ISPs rise and they pass along costs to all
consumers.

Tony

---

From: "William Herrin" <[email-masked]>
Date: Fri, 2 Jan 2009 13:11:14 -0500

> The IRTF operates under the procedures documented in RFC 2014, and under the

Fellas,

Reality check!

The status quo is: the number of entries in the BGP table has
consistently grown and continues to grow year over year since BGP's
inception. See: http://bgp.potaroo.net/

Regardless of pronoun choice, no consensus call is necessary to cite
this well established fact. Had I overreached from this statement, you
might have cause to throw the rulebook at me. Since I didn't, you
don't.

> dollars).

Five bucks says the current trend is the opposite of this. If you
collect the cost data from yesteryear and apply the formula at
http://bill.herrin.us/network/bgpcost.html I bet you find that the
cost per BGP prefix has been gradually falling for some time.

Regards,
Bill Herrin

---

From: "William Herrin" <[email-masked]>
Date: Fri, 2 Jan 2009 13:16:39 -0500

On Thu, Jan 1, 2009 at 2:43 PM, Brian E Carpenter
<[email-masked]> wrote:
>> I insist on me being able to
>> or demand for core routing slots.
>
> Slide 15 in

Thanks Brian.

I follow how slide 15 achieves reliable multihoming given two constraints:

1. System contains client machines. If it contains servers, they are
limited to those protocols which have a thoroughly defined layer-7
multihoming process, such as SMTP.
2. Loss of session during a multihoming event deemed acceptable.

I accept the proposition that some significant fraction of the
multihoming demand could be satisfied with a system meeting criteria
#2. Given a satisfactorily low rate of multihoming events, a pizza
joint is happy as long as the SIP phones immediately re-establish and
the web users can get the page by hitting reload.

I accept that slide 15 offers qualitatively different multihoming
versus slide 16 in that slide 15 does not require hosts to deal with
routing constructs with which they are not presently familiar. When
fleshed out to provide a complete multihoming solution, slide 16
evolves into strategy B.

Question:

What's the cause to believe that systems meeting criteria #1 represent
a more-than-negligible portion of the multihoming demand that is
either unserved or served by BGP?

You may choose to dispute criteria #1. Before you do, I remind you
that the primary API for access to the DNS (gethostbyname) is
irretrievably defective, at least as it pertains to providing an
ephemeral GUID to LOC map.

> So if you were product manager for a highly reliable
> addresses.

Like a web browser, let's say? Think HTTP handles this? Think again.
Once the browser successfully connects to a particular IP address for
a given server name, it nails itself to that address in order to avoid
an otherwise unsolvable javascript+DNS hacking vector.

Regards,
Bill Herrin

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 03 Jan 2009 09:11:54 +1300

Bill,

> multihoming process, such as SMTP.

Yes, layer 7 has to be able to cope with this.

> 2. Loss of session during a multihoming event deemed acceptable.

Yes, which implies that layer 7 transactions must have intrinsic
robustness (not a new idea in the transaction processing business).

> fleshed out to provide a complete multihoming solution, slide 16

Correct.

> either unserved or served by BGP?

Well, I believe that all successful transaction-style layer 7s meet
this and have done since the earliest days of on-line transaction
processing. And I think there's a reason why the large business systems
of today are built on top of web services namespaces or similar, which
form an abstraction layer that basically hides *everything* we're talking
about here. But, indeed, anything that rides directly on the socket API
is exposed (a bit less so with getaddrinfo than gethostbyname, however).
> an otherwise unsolvable javascript+DNS hacking vector.

Indeed. I'm no lover of the Web Services monster, but again - that's
why they use a namespace abstracted above DNS and run their own security
at layer 7.

     Brian

---

From: "Tony Li" <[email-masked]>
Date: Fri, 2 Jan 2009 12:25:32 -0800

Hi Bill,

|The status quo is: the number of entries in the BGP table has
|consistently grown and continues to grow year over year since BGP's
|inception. See: http://bgp.potaroo.net/

Reality check indeed: that's simply not true.  There are several blips where
there has been a decline.  Early 2001 and 2004 appear obvious.  And if the
graph were a bit larger, you'd see the post-CIDR decline.

Tony

---

From: "William Herrin" <[email-masked]>
Date: Fri, 2 Jan 2009 15:40:46 -0500

> graph were a bit larger, you'd see the post-CIDR decline.

In 15 years of data, the only start points you can pick in the graph
which were not higher 12 months later are within that short blip in
2001. What's more, the blip is clearly an outlier: only one of the
several BGP feeds plotted exhibits that behavior. Even for the blip,
they're higher 24 months later.

Regards,
Bill Herrin

---

From: "Tony Li" <[email-masked]>
Date: Fri, 2 Jan 2009 15:14:54 -0800

|In 15 years of data, the only start points you can pick in the graph
|which were not higher 12 months later are within that short blip in
|2001. What's more, the blip is clearly an outlier: only one of the
|several BGP feeds plotted exhibits that behavior. Even for the blip,
|they're higher 24 months later.

Thank you, that's much more accurate.

Tony