Subject: Re: [BEHAVE] Please move this thread to BEHAVE mailing list ... Was Re: Lack of need for 66nat : Long term impact toapplicationdevelopers

From: "Tony Hain" <[email-masked]>
Date: Mon, 1 Dec 2008 11:30:41 -0800

Cullen Jennings wrote:
> I'm sure that the IAB and IESG is keenly interested in this topic but
> everyone that cares is subscribed to behave. 

While I agree that everyone interested in defining nat behavior is
subscribed to Behave, I doubt that everyone in the application community is,
yet every one of them will be impacted by the fundamental architectural
implications of this backroom rush to market effort. There has been no
justification of the need for a 66nat, only wild claims that we need to do
something now because people will be shipping them in the next few months.
While I have no doubt that vendors will ship what their customers are asking
for, it is not clear that the IETF should endorse an effort with such a wide
ranging architectural impact. Never mind that if the vendors are really
shipping in the next few months there is no chance that an IETF document
would be published before there are products on the street....

Hosting this discussion in Behave assumes the outcome, and is absolutely the
wrong place for an architectural discussion. This should be held in the
Applications area, and only moved to Behave to resolve the implementation
details once it is decided that a 66nat is absolutely necessary. Trying to
do it by having people pre-disposed to an answer and without any concern for
the impact to the application community is guaranteed to result in
perpetuating an unnecessary architectural wart.

Tony

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

---

From: james woodyatt <[email-masked]>
Date: Mon, 1 Dec 2008 11:57:47 -0800

[distribution narrowed somewhat]

On Dec 1, 2008, at 11:30, Tony Hain wrote:
> Cullen Jennings wrote:
>>
>> I'm sure that the IAB and IESG is keenly interested in this topic  
>> but everyone that cares is subscribed to behave.
>
> [...] Hosting this discussion in Behave assumes the outcome [i.e.  
> the need to standardize on NAT66 behavior], and is absolutely the  
> wrong place for an architectural discussion. [...]

I wish to second Mr. Hain's specific remark that I quoted above.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 02 Dec 2008 09:35:59 +1300

James,

Without analysing that idea in detail, it seems very much
like what Proxy SHIM6 would achieve.

Yes, I did write something like this up for IPv4 in 1994 :-)
But it was half baked...

   Brian

On 2008-12-01 15:11, james woodyatt wrote:
> On Nov 30, 2008, at 14:23 , Brian E Carpenter wrote:
>> On 2008-12-01 10:12, james woodyatt wrote:
>> ...
>>> By standardizing the behavior of NAT66, and thus issuing an IETF and IAB
>>> blessing of it, we will be giving the pathogen of NAT exactly the
>>> vectors it needs to spread with highest efficiency through the IPv6
>>> public Internet.
>>
>> Then you need to hurry over to the RRG and invent an alternative
>> solution to the multihoming problem that is acceptable to application
>> writers, o/s writers, router and CPE vendors, ISPs, and site IT managers
>> alike.
> 
> I suspect the "acceptable to application writers, o/s writers, router
> and CPE vendors, ISPs, and site IT managers alike" condition is the one
> on which we are all hanging.  For a significant fraction of those
> communities, nothing less than NAT à la IPv4 will suffice for reasons
> that cannot be articulated.
> 
> I know what I'd propose as an alternative to NAT for the multihoming
> problem, but I suspect it has already been rejected by one of those
> communities basically on the grounds that it isn't full-blown NAT à la
> IPv4, which is the only thing that can be ever be acceptable to somebody
> with enough clout to stall any alternative that might arise.
> 
> Here's what I'd do: define a new end-to-end extension header, kinda like
> the existing source routing header, but intended to be packed by... let
> us say... a certain kind of border gateway rather than the initiating
> endpoint node.  In the "outbound" flow, the source address in the outer
> IPv6 header would be replaced with a source address configured by the
> gateway, and the original source address would be pushed into the
> extension header.  The rule would be that transport protocols must use
> the source address at the bottom of the stack when composing the
> pseudo-header for payload verification.  Transport endpoints would also
> be required to respond in the reverse direction by copying the extension
> header from the most recently received packet from the destination
> transport address.  Routers receiving packets in the reverse flow would
> be responsible for unpacking those extension headers the same way they
> are packed in the forward direction.  Transport endpoints would not use
> this extension header for the initial packet in a flow.
> 
> In this fashion, IPv6 nodes capable of processing this extension header
> might receive flow initiations from anywhere on the Internet, including
> nodes without globally reachable interface addresses.  Depending on
> administrative policy, this extension could also be used to permit
> servers to be made available to any subset of the global Internet on
> nodes that do not have any globally reachable interface addresses so
> long as the routers configured to push these extension headers for them
> are using globally routed addresses which the clients can use to
> initiate flows.
> 
> I think this would more than adequately address all the multihoming
> concerns without requiring the use of NAT.  It would make operating
> systems vendors sad, but not *that* sad, because it's not like IPv6 is
> completely unusable without this extension.  They could roll it out
> around the same time they get around to rolling out MIPv6, MLDv2, etc. 
> Speaking as a CPE gateway developer, I can say I'd much rather have a
> standard like this than have to respond to marketing demands for NAT66
> kludgery.  Testing an encapsulation mechanism is a lot easier than
> testing a full-blow NAT implementation.
> 
> Where I predict this proposal will meet with hostile resistance is from
> site IT managers who I will likely find it unacceptable because it
> discloses the internal addresses of endpoint nodes in their private
> networks to networks outside their control.  Many of these people want
> full-blown port-changing NAT66 for its topology hiding function, despite
> its dubious security value in real, measurable terms.  I contend those
> people have yet to put forward an explanation for this demand that
> stands up to rational analysis.  They've had plenty of time to do so,
> and lately, it seems like they've stopped trying altogether.  To me,
> they seem to be saying simply that they need NAT66 because nothing else
> will soothe their emotional discomfort with IPv6 migration issues. 
> [Inappropriate summarizing rhetoric, using words like "crackpot" and
> "stupid," deleted for the sake of comity.]
> 
> So, okay— where is the draft, which was no doubt written up ten years
> ago by somebody like Brian Carpenter, that does what I'm proposing
> above?  I'd like to read the archives to see how and why it got shot down.
> 
> 
> -- 
> ------------------------------------------------------------------------
>

---

From: Keith Moore <[email-masked]>
Date: Mon, 01 Dec 2008 15:52:05 -0500

> perpetuating an unnecessary architectural wart.

Mumble.  As usual in IETF when we are talking about issues that have a
profound effect on the architecture, the discussion is fragmented.

- The greatest concentration of NAT experts in the IETF are probably in
the BEHAVE group.  They do have a NAT-centered view of the
problem/solution space.  But don't discount them entirely, as many of
the participants in that group have a deeper grasp of the implications
of NAT (at least when viewed from that angle) than the average IETF
participant.

- Some of the pressure to have NATs (other than for IPv6 transition)
seems to be coming from routing area people who can't figure out how to
make the core routing scale, so they want to push part of the problem to
the edges.   So clearly we need input from routing people.

(I'm not saying it's an inherently unreasonable approach, though
sometimes I do wonder if it smacks of "let's make this somebody else's
problem so we don't have to deal with it".  And BTW, no area has a
monopoly on this kind of wishful thinking.)

- Other pressures to have NATs are from network operators who see it
(and not entirely without justification, though in some cases it's
marginal) as something that helps their security and/or decreases their
management effort in the face of (a) renumbering and/or (b) reducing
granularity of access control.  So we need input from operations people
also, though it's not clear (to me anyway) how well those people are
represented in IETF.

- And of course we also need input from applications people.  But
historically most IETF standard applications protocols have not been
peer-to-peer or distributed apps.  So IETF applications area people (in
general) may actually not be adequately sensitive to the needs of apps
outside of the two-party (i.e. client-server) space.  This implies that
moving this discussion to an apps area group would not automatically
bring with it a lot of clue about how NATs affect apps.    But we
certainly need input from people with distributed / p2p apps expertise.

--

I haven't followed IETF as closely for the past few years as I did for
the decade or so before that.  But in the past it used to be the case
that ADs would deliberately narrow the scope of some of these
discussions to avoid endless ratholes in discussion between people who
could never learn to speak the same language, or respect one another's
experience or needs.  I don't know if that tactic is still being used,
but my impression from some distance is that IETF is even more
fragmented about architectural issues (particularly use of NATs) than it
used to be - though today it seems that a bit more of the NAT discussion
is coalescing in BEHAVE than it was, say, a year ago.  And having the
discussion in a single WG is IMO far better than having a half-dozen
different groups all trying to solve more-or-less the same problem, from
narrow points-of-view, in relative isolation from one another.

I guess what I'm concluding is this:  Yes, we need to have input from
all of these different kinds of people.  Yes, the BEHAVE group has a
NAT-centric view.  But unless we can find some way to get a more diverse
set of interests into the same (virtual) room AND get them to actually
speak the same language and respect one another's views, moving the
discussion elsewhere isn't going to help convergence of any kind of
solution - with or without NAT.

But IF the discussion is going to happen there, what I'd really like is
for the BEHAVE group to stop trying to enumerate and define in detail
every possible solution to the NAT problem -- and instead focus on
developing a single, common framework that would let NATs provide the
functionality and visibility that both applications and operators need.

If they were to take that approach, I think they could do a decent job
at defining the "Optimal" NAT and also enumerating its warts.  And then
the rest of us could look at it and see how bad (or tolerable) it really
is.  And the routing people could look at it and see if it's really
possible to use NATs to handle multihoming to stub networks, without
painting the internet architecture into an undesirable corner.

(Because at present the "we need NATs for routing" argument looks, to my
intuition, a bit like handwaving.   And I am not convinced that the
proponents of using NATs to simplify the routing problem really
understand the implications of doing that, either for the applications
or for the internet architecture in general. But I do think that it's
worth exploring that, and that the proponents of this approach need to
be able to make the best case they can for it.  And in order to do that
they really need a definition of "optimal NAT" to work with.)

Keith

---

From: Dan York <[email-masked]>
Date: Mon, 1 Dec 2008 17:27:56 -0500

I would suggest that there is at least one other block of people who  
are missing from the list of stakeholders in the "To NAT or not to NAT  
in IPv6" discussion that Keith Moore listed:

On Dec 1, 2008, at 3:52 PM, Keith Moore wrote:

> the BEHAVE group.  <snip>
> seems to be coming from routing area people <snip>
>
> - Other pressures to have NATs are from network operators <snip>
>
> - And of course we also need input from applications people.  <snip>

.... namely:

- The system/network administrators and network architects at  
companies/enterprises who are managing and deploying enterprise  
networks.

I don't know how well this particular group is represented within the  
IETF.  I know there are some people from that group at IETF meetings  
because I've met a few. But only a few. My sense from interacting with  
a good number of them over the past 10 years or so is that they are  
probably way too busy dealing with their networks to be involved with  
what goes on here inside of the IETF.  In fact, in some conversations  
over the years where I brought up the IETF with some folks in the sys/ 
netadmin space, the IETF (if it was known, which was not always the  
case) was this vague amorphous body out there "making standards".  But  
that was it.  Relevance of the IETF to their daily job was viewed as  
slim to none.

Now this group is also the group setting up enterprise networks,  
allocating IP addresses, deploying infrastructure, etc.

And they pretty much all use NAT.  And the ones I've talked to all  
*like* NAT.

Sure, they have to use NAT with IPv4 in many/most network situations,  
but I've known of companies with large IPv4 address blocks  
(unfortunately the names escape me right now) who *chose* to use NAT  
and RFC1918 addresses and to not use much of their large IPv4 blocks  
internally.  Why?

Control.

As has been pointed out by others in this thread, there is immense  
value to a company/organization/entity in maintaining control over  
their IP addresses.  They are not locked into their current ISPs...  
with a sufficient amount of randomness they can hopefully easily  
integrate with other acquisitions... they don't have to renumber,  
etc., etc.... the various reasons people have pointed out.

I personally don't see them ever giving up NAT.

Oh, we can point out how broken it makes their networks... we can  
point out how IPv6 apps will work so much better without NAT.... we  
can point out how ULA and RFC 3484 make NAT unnecessary.

Some will listen.  Some will use ULAs and put in place the appropriate  
routing policies, etc. to make it all work.

Others - and I personally think it will be *most* - will simply just  
NAT their IPv6 network just exactly like they did for their IPv4  
network.  Why?

Because it's simple and easy and **that's what they know**.  They  
maintain all the control they want.  They have even fewer external IP  
addresses to think about (just the ones on the NAT boxes).  Many view  
NAT as part of a security plan with topology-hiding, etc. (And yes, we  
can argue debate that point endlessly, too.)  To them, it makes their  
lives simpler, reduces the workload they have, etc., etc.

We can argue that they shouldn't think this way... that with IPv6 they  
have a new and better way to do things... but these are the same folks  
who are just-trying-to-keep-their-networks-running-while-not-having- 
their-jobs-outsourced-as-their-budgets-are-being-cut-and-they-just- 
want-to-keep-things-stable-while-the-idiot-on-the-second-floor-keeps- 
losing-their-system-password-and-the-turkey-on-the-third-floor-has- 
somehow-deleted-their-critical-document-for-the-zillionth-time-and-the- 
marketing-people-want-web-2.0-apps-implemented-yesterday-and-the-CFO- 
is-demanding-better-realtime-stats-and-oh-by-the-way-another-company- 
was-just-acquired-and-needs-their-network-to-be-integrated-and-the- 
pager-going-off-at-2am-every-night-this-week-is-getting-really-really- 
old-and....and....and...and...and-now-the-CIO-says-that-we-have-to- 
have-IPv6-addresses-deployed-by-next-month...

I think NAT will go away for these folks when we pry the cold dead  
fingers of the last sysadmin away from the keyboard...

I'd love to be wrong on this, but I think a great number of enterprise  
IT folks actually like NAT and will continue to use it even as they  
move into IPv6.  Our choice within the IETF seems to me to be either  
ignoring it entirely and hoping that somehow all these networks will  
"see the light" and embrace networks without NAT - or alternatively to  
come up with ways that NAT can work in IPv6 spaces (while still  
encouraging people to look more at how to deploy without NAT).

And to return to my original point, I think we need to see if there  
are ways to include more people from the actual system/network admin  
sphere into these discussions.... (unless I'm wrong and that segment  
is already very well represented and I just haven't noticed)...  
because at the end of the day, *they* are the ones who are actually  
going to be implementing (or not) all these standards we create.

My 2 cents,
Dan

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Build voice applications based on open standards.
Find out how at http://www.voxeo.com/free

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 02 Dec 2008 12:02:25 +1300

Keith,

With some reluctance, I have't changed your cc list. But
my conclusion is that this particular discussion belongs
on the RRG list as much as anywhere.

On 2008-12-02 09:52, Keith Moore wrote:
...
> intuition, a bit like handwaving. 

I don't think that is quite the argument. It is more like this:

1. We know of no alternative to a longest-match based approach to
routing lookup for the inter-AS routing system (commonly known
as the DFZ).

2. To control the long-term scaling of that approach, we need to
control the long-term size of the lookup table and the long-term
rate of dynamic updates to that table.

3. We assume there will be continued unbounded growth in the
number of sites requiring multihoming, but today each site that
requires multihoming thereby requires its own entry in the DFZ
lookup table. In the long term, this is unsustainable.
[Digression about numbers and dates omitted.]

4. The known solutions to this all require some mechanism for
aggregating site prefixes into ISP prefixes. [There's space for
a digression about the related advantages of separating
the transport ID from the network address, and about the
application layer's view of all this, but that doesn't
affect what I just said.]

5. One solution to that is a multi-prefix model (a site runs
multiple prefixes), which is of course the IPv6 design assumption.
Another solution is a map-and-encap model. A third solution is
a map-and-translate model. There are many variants of all these
models, but I don't know of a fourth one. All solutions have
advantages and disadvantages.

IMHO the reason we're hearing about NAT66 is because people
still find the IPv6 multi-prefix model unfamiliar and there is
no consensus-based map-and-encap solution yet. So it's natural
to look at map-and-translate, and NAT66 is one of the solutions
in that category.

    Brian

---

From: james woodyatt <[email-masked]>
Date: Mon, 1 Dec 2008 17:07:41 -0800

On Dec 1, 2008, at 12:35, Brian E Carpenter wrote:
>
> Without analysing that idea in detail, [...]

That's good, because I think I missed a major detail-- though, not one  
that can't be addressed easily: the extension needs to be able to  
support two stacks of addresses, for both source and destination.

> [...] it seems very much like what Proxy SHIM6 would achieve.

So, I went off today and skimmed the Proxy SHIM6 draft, and at first  
glance it seems like a lot more complexity than what I have in mind.   
It talks about a DNS ALG and, yes: NAT66, and I don't at all see a  
powerful reason to lump all that stuff together with a basic map-and- 
encap solution to the single-ULA-prefix multi-homing problem.

I'll need to study Proxy SHIM6 (and similar) further and figure out  
what I really think.  My initial think is that the problem isn't  
nearly so hard to solve as that.

> Yes, I did write something like this up for IPv4 in 1994 :-)

I have a hard time believing that what I have in mind hasn't been  
proposed six or seven times already by people a million times smarter  
than I am.

On December 1, 2008 15:02:25 PST, Brian E Carpenter also wrote in  
another thread:

> IMHO the reason we're hearing about NAT66 is because people still  
> find the IPv6 multi-prefix model unfamiliar and there is no  
> consensus-based map-and-encap solution yet. So it's natural to look  
> at map-and-translate, and NAT66 is one of the solutions in that  
> category.

This is just about the clearest and most depressing summation of the  
current state of play that I've seen.  Where it comes up short, I  
would say, is that it fails to mention that NAT66 is an idea packed to  
the gills with toxic architectural implications.  This is not news to  
anyone in the BEHAVE working group.  Yet, deciding that those  
considerations weigh less than both A) the unfamiliarity of the multi- 
prefix model among the IPv6 user community, and B) the lack of  
consensus around a map-and-encap proposal, which is the implication of  
holding this discussion in the BEHAVE group [rather than somewhere in  
IRTF or better still: the IAB]... making that decision seems absurdly  
premature to me.

Have we really given up on reaching consensus about a map-and encap  
solution for single-prefix multi-homing?

Okay... I suppose I should be resigned to the inevitability that IAB  
will end up capitulating in its architectural resistance to NAT66.   
(This assumes that it hasn't already capitulated, and I just haven't  
heard about it yet.)  I'd much rather be involved in hunting for a  
superior map-and-encap solution than get myself mired in the work on  
taming the NAT66 beast.  Where do I go to be a useful contributor  
instead of a pain in the neck?

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 1 Dec 2008 17:47:07 -0800

> [Digression about numbers and dates omitted.]

This does not necessarily follow ... Even so, we could easily scale a couple of orders of magnitude from the existing number of multihomed edge networks, so they aren't the problem. The fundamental problem with route scaling is that people choose to pollute the system to do rudimentary traffic engineering with BGP. 

> aggregating site prefixes into ISP prefixes.

BS... Containing the size requires aggregation, but ISP based prefixes is a choice rather than a requirement.

> [There's space for
> models, but I don't know of a fourth one. 

Choosing to ignore Geo approaches does not make them go away. Yes that means that topology would have to follow routing rather than the other way around, but that could be done at a global scale with regional deaggregates where routing follows topology and the result would be carving up the scaling problem to whatever size ISPs could get routers to support. 

> All solutions have advantages and disadvantages.

True enough, and geo requires the ISPs to consider something besides local optimization at a cost to the entire rest of the world. These are all trade-offs...

> to look at map-and-translate, and NAT66 is one of the solutions

While that is somewhat true, the majority of the reason has been clearly stated by the proponents: Vendors are building 46/64, and will be throwing in 66 just because they can. There has been no outcry from the masses trying to deploy IPv6, it is strictly vendor driven because they want something they can point to as justification for building something that is totally unnecessary. 

Tony

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 1 Dec 2008 19:20:37 -0800

Fair Enough. I was not thinking of the behave mailing list as  
presuming the answer but I see your point.

---

From: Keith Moore <[email-masked]>
Date: Mon, 01 Dec 2008 23:37:04 -0500

> advantages and disadvantages.

Nice summary.  I mostly agree with all of the above.

> to look at map-and-translate, and NAT66 is one of the solutions

I don't think it's just that the multi-prefix model is unfamiliar.
There's plenty of reason to believe that it won't work well. Static
address selection rules, no way for hosts to know which prefixes will
work better, inability of most existing transport protocols to fail over
 to alternate addresses.  I won't claim that the problems can't be
fixed, but I don't think they're solved problems yet - so this looks
like moving a problem rather than fixing it.  And it also blurs the
division between the network's responsibility and the host's
responsibility, which doesn't seem like a good thing.

Regarding map-and-translate: To me it seems important to make a clear
distinction between the case where a network at the edge uses a NAT to
translate between "private" addresses (e.g. ULAs) and PA addresses
(which is what I understand NAT66 to be); and the case where there
address translation is done by routers at the edge of the network core
in order to efficiently transmit packets through the network, and the
inverse translation is done when the packet exits the core so the packet
as received has the same source and destination addresses as the one
sent.  Even if the hardware required to do the two kinds of translation
is pretty similar, the impact on applications is very different.  I
don't think the latter would have much effect on apps at all, though it
would affect diagnostic tools.

It would be really interesting to try to evaluate each of multi-prefix,
map-and-encap, and map-and-translate according to (a) how much each
approach affects applications and hosts in general, and (b) how
deployable each approach is - where deployability has a lot to do with
having the parties that benefit most (probably those that want to
multihome) being the ones that bear the additional cost, and having the
benefit be worth the cost.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 02 Dec 2008 01:21:41 -0500

David Morris wrote:
> 
> On Mon, 1 Dec 2008, Keith Moore wrote:
> 
> A key analysis point needs to be diagnostic support.. how hard any
> individual approach will be to support is in my mind a significant part of
> the deployability cost analysis.

agreed. absolutely.

and to address Brian's point from a few messages back that maybe this
should be discussed in RRG instead of among the current set of
recipients - does RRG have any established evaluation criteria like
these, with which to compare potential solutions?  if not, why not?

Keith

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 02 Dec 2008 11:01:21 +0100

> perpetuating an unnecessary architectural wart.

Tony,

We had quite some discussion in IESG about where to discuss this topic.
There is no perfect fit. I think it is time to move it from Behave to
its own list as the discussion continues to go on and impacts Behave's
chartered work. However, the issues as you say is that it is an
architectural discussion and it affects all layers from routing up to
application. Which means that we need insights from all layers. But, we
can't continue to have a good discussion by cross posting to all area
list or the [email-masked] list.

Also be certain that we haven't decided anything about what to do with
NAT66, except saying that we are allowing the discussion. There will be
a BOF before anything if any is chartered on this topic.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 2 Dec 2008 11:57:07 +0100

On 2 dec 2008, at 5:37, Keith Moore wrote:

> to alternate addresses.

One way to fix that would be multipath transport protocols. Rather  
than try to guess what works best, just use all of them (or at least  
several) and get better performance without having to make difficult  
choices.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Stig Venaas <[email-masked]>
Date: Tue, 02 Dec 2008 17:13:59 +0100

james woodyatt wrote:
> glance it seems like a lot more complexity than what I have in mind.  It
> talks about a DNS ALG and, yes: NAT66, and I don't at all see a powerful
> reason to lump all that stuff together with a basic map-and-encap
> solution to the single-ULA-prefix multi-homing problem.
> 
> I'll need to study Proxy SHIM6 (and similar) further and figure out what
> I really think.  My initial think is that the problem isn't nearly so
> hard to solve as that.
> 

While following the NAT66 discussion, I also thought that one could do
something like this (and I think it must have been thought of by lots of
people before...).

I can see two issues though. As you say, some may not like it because
they actually want to hide their internal addressing.

The main issue I see, is how can you know that the supplied address
actually belongs to the peer you're talking to?

Stig

---

From: james woodyatt <[email-masked]>
Date: Tue, 2 Dec 2008 10:23:09 -0800

On Dec 2, 2008, at 08:13, Stig Venaas wrote:
>
> I can see two issues though. As you say, some may not like it  
> because they actually want to hide their internal addressing.

These people are expressing a requirement that can only be satisfied  
by NAT66.

Another way of expressing the same requirement is to say that  
numbering some IPv6 site networks in the public IPv6 address realm is  
unacceptable.  However, once you decide that you MUST have private  
IPv6 address realms with capability to reach the public IPv6 Internet,  
you have DEFINED the architectural requirement for NAT66.

This is why I view the argument for NAT66 based on a perceived need  
for site topology hiding as completely tautological.  Translated into  
simple language, the argument is "we need NAT66 because NAT66 is what  
we need."  My response: tell me why you perceive a need for site  
topology hiding, and please do make a point of explaining it without  
indulging in further tautologies, e.g. we need to hide site topology  
because hiding site topology is what we need.

> actually belongs to the peer you're talking to?

What is "the supplied address" you're worrying about here?  How is it  
being supplied?  Without knowing for sure what you're talking about, I  
have to make some assumptions, e.g. that you're talking about the  
source address in packets received at the destination endpoint that  
have the extension header I'm kicking around here.  My answer is that  
the composition of the IPv6 header and its extension header comprise  
the multiple addresses required to resolve the ID/locator split.  I'm  
guessing that the intersection of my idea with IPsec is where the real  
fun might start.

I'll have to think more on this.

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 02 Dec 2008 10:27:39 -0800

> because hiding site topology is what we need.
Just because you think that a self-imposed network architecture 
requirement of hiding internal topology isn't a good enough reason all 
on its own doesn't mean that it isn't a good enough reason for someone 
else to want or require it.

But if you insist, then how about "our SOX compliance auditors have 
non-disclosure of internal network topology as a required checklist 
item" or "our SOX compliance auditors have address translation as a 
required checklist item when verifying that unsolicited external access 
through the firewall is blocked"

Matthew Kaufman

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 2 Dec 2008 19:43:26 +0100

On 2 dec 2008, at 19:27, Matthew Kaufman wrote:

> required checklist item when verifying that unsolicited external  
> access through the firewall is blocked"

I guess we need a liaison to the SOX people then.

If this internal topology is so sensitive, why do these systems get to  
send packets to the outside in the first place? Why not go through  
IPsec tunnels? Or proxies? Externally facing servers can be put in a  
single subnet so there is no topology to hide.

And don't kid yourself, there is plenty of stuff that can't be hidden.  
Just measuring roundtrips can reveal a lot of information.

I'm 99% sure the people who run corporate networks and insist on NAT  
are other people than those who need their peer-to-peer applications  
to work. As long as the first group runs NAT and the second group  
doesn't, everyone is happy. The trouble start when we start to overlap  
the groups.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 2 Dec 2008 19:45:49 +0100

> It's not clear to me from the above whether you mean something
> like "use SCTP",

Note that although SCTP is aware of multiple addresses, it won't  
actually use them concurrently. What I have in mind is a TCP that can  
use multiple paths at the same time. For the purposes of this  
discussion that would have to be a multiaddressing aware multipath TCP  
or a multipath TCP integrated with shim6/MIPv6.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Keith Moore <[email-masked]>
Date: Tue, 02 Dec 2008 13:48:02 -0500

> else to want or require it.

right.  but long ago, someone decided that one of the benefits of NAT
was hiding internal topology, and they sold that idea to other people.
since then it's become conventional wisdom that hiding internal topology
  is one of those things that you should do to protect your network.

it's highly doubtful that for the vast majority of networks anyone has
identified a specific, credible threat resulting from external
visibility of a network's topology.  it's even less likely that in those
cases where such a threat was identified, anyone did a cost-vs-benefit
analysis of the decision to use NAT or not use NAT.

Keith

---

From: james woodyatt <[email-masked]>
Date: Tue, 2 Dec 2008 10:52:27 -0800

On Dec 2, 2008, at 10:27, Matthew Kaufman wrote:
> requirement of hiding internal topology isn't a good enough reason  
> all on its own doesn't mean that it isn't a good enough reason for  
> someone else to want or require it.

I understand that non-technical arguments often carry weight in non- 
technical discussions.  Last I checked, however, the 'E' in IETF  
stands for Engineering, so I hope to be forgiven for thinking that  
working group mailing lists are where we conduct *technical*  
discussions.

> item" [...]

Okay.  And, your SOX-compliance requirements cannot be satisfied by  
something like a SOCKS proxy service because...?

> or "our SOX compliance auditors have address translation as a  

Okay.  And, the reason your SOX-compliance auditors are using a brain- 
damaged requirements checklist is...?

Bring these SOX-compliance auditors here.  Let them explain themselves  
to us.  Perhaps we can set them straight and avoid trashing the  
foundations of the Internet architecture because we allowed such  
technical ineptitude to go unchallenged.

---

From: Scott Brim <[email-masked]>
Date: Tue, 2 Dec 2008 13:52:31 -0500

Excerpts from Brian E Carpenter on Tue, Dec 02, 2008 12:02:25PM +1300:
> routing lookup for the inter-AS routing system (commonly known as
> the DFZ).
> 
> 3. We assume there will be continued unbounded growth in the number
> of sites requiring multihoming, but today each site that requires
> multihoming thereby requires its own entry in the DFZ lookup table.
> In the long term, this is unsustainable.  [Digression about numbers
> and dates omitted.]
> 
> aggregating site prefixes into ISP prefixes. [There's space for a
> digression about the related advantages of separating the transport
> ID from the network address, and about the application layer's view
> of all this, but that doesn't affect what I just said.]
> 
> Another solution is a map-and-encap model. A third solution is a
> map-and-translate model. There are many variants of all these

All good but 

> to look at map-and-translate, and NAT66 is one of the solutions

My suspicion is that it's seen as easier to deploy, right now.  Show
me your IPv6 multiprefix deployments, now show me your NAT
deployments.  And NAT66 is just NAT, right?  

Scott

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 2 Dec 2008 13:55:26 -0500

Hi James,

On Nov 30, 2008, at 9:11 PM, james woodyatt wrote:
>
> Here's what I'd do: define a new end-to-end extension header, kinda  
> like the existing source routing header, but intended to be packed  
> by... let us say... a certain kind of border gateway rather than the  
> initiating endpoint node.  In the "outbound" flow, the source  
> address in the outer IPv6 header would be replaced with a source  
> address configured by the gateway, and the original source address  
> would be pushed into the extension header.  The rule would be that  
> transport protocols must use the source address at the bottom of the  
> stack when composing the pseudo-header for payload verification.   
> Transport endpoints would also be required to respond in the reverse  
> direction by copying the extension header from the most recently  
> received packet from the destination transport address.  Routers  
> receiving packets in the reverse flow would be responsible for  
> unpacking those extension headers the same way they are packed in  
> the forward direction.  Transport endpoints would not use this  
> extension header for the initial packet in a flow.
>
> In this fashion, IPv6 nodes capable of processing this extension  
> header might receive flow initiations from anywhere on the Internet,  
> including nodes without globally reachable interface addresses.   
> Depending on administrative policy, this extension could also be  
> used to permit servers to be made available to any subset of the  
> global Internet on nodes that do not have any globally reachable  
> interface addresses so long as the routers configured to push these  
> extension headers for them are using globally routed addresses which  
> the clients can use to initiate flows.

If I'm understanding your thoughts correctly, I wrote an incomplete  
draft along the same lines about 18 months ago and floated it to some  
reviewers...  There were (not surprisingly) some technical challenges  
with this approach, but perhaps not insurmountable ones.  At the time,  
though, I didn't have enough support from my then-employer to work on  
the idea, and there were other good proposals floated as part of the  
RRG efforts that were gaining a lot of mindshare (LISP, etc.), so I  
never got around to posting the draft.

So, if you think you might want to work on something along these  
lines, I'd be happy to participate and contribute.  I can even offer a  
partial draft as a starting point, which I posted today so that you  
(and anyone else who is interested) can read it:

http://www.ietf.org/internet-drafts/draft-mrw-ram-trip-00.txt

> systems vendors sad, but not *that* sad, because it's not like IPv6  
> is completely unusable without this extension.  They could roll it  
> out around the same time they get around to rolling out MIPv6,  
> MLDv2, etc.  Speaking as a CPE gateway developer, I can say I'd much  
> rather have a standard like this than have to respond to marketing  
> demands for NAT66 kludgery.  Testing an encapsulation mechanism is a  
> lot easier than testing a full-blow NAT implementation.

This approach also has some very nice incremental deployment  
properties, IMO.
>
> So, okay— where is the draft, which was no doubt written up ten  
> years ago by somebody like Brian Carpenter, that does what I'm  
> proposing above?  I'd like to read the archives to see how and why  
> it got shot down.

Sadly, my draft wasn't written by Brian Carpenter, so you'll have to  
suffer through my prose, instead.  Also, it wasn't proposed on a  
public list, so there are no archives of the issues.

There are security concerns, a need for some significant DNS tie-ins,  
and a problem with the fact that we've suggested (in a v6ops  
document)  that IPv6 routers (or is it just firewalls?) discard  
packets with unknown IPv6 extension headers...  It's not clear how/if  
those could be worked around.  Perhaps the last one could be avoided  
if we implement a backoff such that if the first attempt doesn't get  
through, we re-try without the extension header?

Anyway, please read my draft and let me know if it matches with what  
you're discussing.  If you are interested in pursuing this idea any  
further, I could probably dig out the messages on this topic from my  
personal mail archives.

Margaret

---

From: Dan York <[email-masked]>
Date: Tue, 2 Dec 2008 13:57:07 -0500

Keith,

On Dec 2, 2008, at 1:48 PM, Keith Moore wrote:

>> all

And to me it's even *less* likely that we in the IETF will be able to  
change the prevailing "conventional wisdom" that a NAT benefit is  
hiding internal topology and somehow get people to reject what they've  
read in articles or been taught in classes or been taught by mentors.  
They will seek to deploy NAT with IPv6 because they perceive value in  
NAT.

My 2 cents,
Dan

---

From: Scott Brim <[email-masked]>
Date: Tue, 2 Dec 2008 14:02:47 -0500

Excerpts from Iljitsch van Beijnum on Tue, Dec 02, 2008 11:57:07AM +0100:
> One way to fix that would be multipath transport protocols. Rather than 
> try to guess what works best, just use all of them (or at least several) 
> and get better performance without having to make difficult choices.

This doesn't help with site renumbering problems, just endpoint
renumbering.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 2 Dec 2008 20:07:17 +0100

On 2 dec 2008, at 19:55, Margaret Wasserman wrote:

> that IPv6 routers (or is it just firewalls?) discard packets with  
> unknown IPv6 extension headers...  It's not clear how/if those could  
> be worked around.  Perhaps the last one could be avoided if we  
> implement a backoff such that if the first attempt doesn't get  

This is a host requirement, which probably makes sense in any case,  
but is a requirement because options don't have a fixed format so  
there is no sure way to parse whatever follows an unknown option.

But don't forget that it's still early days in IPv6, it's still  
possible to force in new features even if that breaks backward  
compatibility if those features are compelling enough, both because  
broken IPv6 isn't lethal because (almost?) nobody runs v6-only and  
because presumably, all installations running IPv6 are still actively  
maintained and updated.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "Eric Klein" <[email-masked]>
Date: Tue, 2 Dec 2008 21:07:47 +0200

On Tue, Dec 2, 2008 at 20:52, james woodyatt <[email-masked]> wrote:

>> or "our SOX compliance auditors have address translation as a required
>> checklist item when verifying that unsolicited external access through the
>> firewall is blocked"
>>
>>
>> Okay.  And, the reason your SOX-compliance auditors are using a
>> brain-damaged requirements checklist is...?
>>
>> Past router and security experts told them this was needed in order to
secure the network and no one has updated the documents as there is no
consensus on the need?
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 2 Dec 2008 14:09:05 -0500

On Dec 2, 2008, at 1:43 PM, Iljitsch van Beijnum wrote:
> doesn't, everyone is happy. The trouble start when we start to  
> overlap the groups.

The important point to remember is that _we_ don't overlap the  
groups.  Network administrators decide what they want to run on their  
networks.  Some network administrators believe that the advantages of  
NAT (many of which have been discussed here recently) outweigh the  
costs or alternative solutions.  Other network administrators will  
decide that the need for direct peer-to-peer applications out-weighs  
the benefit they would get from NAT.

I expect this trade-off to be different in IPv6 than it was in IPv4.

If I had to guess, I'd say that deployment of NAT in homes by  
consumers will be substantially less common in IPv6 than in IPv4,  
because home users will not need an IPv6 NAT to share one IPv6 address  
across multiple hosts like they do in IPv4.  Folks will probably still  
buy a home gateway, but hopefully that home gateway will include a  
firewall (to cover the "simple security" requirement), will use DHCP- 
PD to get a prefix for home use (instead of just using net 10) and  
will use Router Advertisements and/or DHCPv6 to configure hosts on the  
home network.  NAT isn't really needed for the typical home user who  
doesn't care about stable addressing, multihoming, topology hiding, etc.

Meanwhile, enterprise administrators will want IPv6 NAT for the many  
reasons we've discussed.  I think we know how to cover some of these  
requirements ("simple security" via firewalls, any others?) using  
other technologies, but we don't (IMO) have a compelling answer for  
how enterprises will achieve the "address autonomy" and "topology  
hiding" benefits of NAT without using NAT.  We can envision a very  
simple NAT device that will offer address autonomy, and a more complex  
NAT device that will offer topology hiding, and I think that we can  
define those things in a way that is less damaging to the Internet  
than IPv4 NA(P)T.  So, I think we should.

There will be a cost to using these devices, just as there is a cost  
(in reachability) to using firewalls.  We can document the trade-offs,  
but don't think we should try to tell informed people that they are  
making the wrong choices for their network.

Margaret

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 2 Dec 2008 20:11:53 +0100

On 2 dec 2008, at 20:02, Scott Brim wrote:

>> than

> This doesn't help with site renumbering problems, just endpoint

NAT also helps very little with renumbering. The only thing that it  
buys you is that you don't have to renumber routers and other devices  
that have their addresses configured staticially sitting behind the  
NAT. But routers can receive prefixes over DHCPv6 and then use those  
prefixes to number their stuff rather than have this done by hand, so  
there is _very_ little need for static address configuration.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "Eric Klein" <[email-masked]>
Date: Tue, 2 Dec 2008 21:20:59 +0200

On Tue, Dec 2, 2008 at 21:09, Margaret Wasserman <[email-masked]> wrote:

>> I'm 99% sure the people who run corporate networks and insist on NAT are
>> other people than those who need their peer-to-peer applications to work. As
>> long as the first group runs NAT and the second group doesn't, everyone is
>> happy. The trouble start when we start to overlap the groups.
>>
>
> The important point to remember is that _we_ don't overlap the groups.
>  Network administrators decide what they want to run on their networks.
>  Some network administrators believe that the advantages of NAT (many of
> which have been discussed here recently) outweigh the costs or alternative
> solutions.  Other network administrators will decide that the need for
> direct peer-to-peer applications out-weighs the benefit they would get from
> NAT.
>
> If I had to guess, I'd say that deployment of NAT in homes by consumers
> will be substantially less common in IPv6 than in IPv4, because home users
> will not need an IPv6 NAT to share one IPv6 address across multiple hosts
> like they do in IPv4.  Folks will probably still buy a home gateway, but
> hopefully that home gateway will include a firewall (to cover the "simple
> security" requirement), will use DHCP-PD to get a prefix for home use
> (instead of just using net 10) and will use Router Advertisements and/or
> DHCPv6 to configure hosts on the home network.  NAT isn't really needed for
> the typical home user who doesn't care about stable addressing, multihoming,
> topology hiding, etc.
>

I am not sure that I agree with this for 2 reasons:
1. we don't know that home users will not get large blocks of addresses from
their ISPs. We propose /48 per site and they could go for much smaller under
the theory that home users don't need them so why waste them (again same
philosophy as in v4).

2. Home users are even less likely to do something diffrent because we told
them to. If their CPE defaults to using NAT inside (with DHCPv6) then it
will be there even if they don't know it. Also field techs (not net admins)
install this stuff and they know what to do by rout not by technicial
benifits - so if it is there they will install it as they always have even
if not needed.

> requirements ("simple security" via firewalls, any others?) using other
> technologies, but we don't (IMO) have a compelling answer for how
> enterprises will achieve the "address autonomy" and "topology hiding"
> benefits of NAT without using NAT.  We can envision a very simple NAT device
> that will offer address autonomy, and a more complex NAT device that will
> offer topology hiding, and I think that we can define those things in a way
> that is less damaging to the Internet than IPv4 NA(P)T.  So, I think we
> should.
>
Here is one more consideration on why ISPs would want NAT - they run
multiple networks which by defination are required to not be reachable from
each other so public addresses can pose a problem unless they are isolated
or firewalled. These networks are the public network that provides services
to their customers, their internal network for day-to-day departmental work
(finanance, HR, marketing, legal, etc.) which need to be some bit isolated
and hack proof, and the network managment network - this one controls their
network and collects billing info etc. and for security reasons they don't
want customers using it.

NAT is one way that they have always seperated them beyond isolation and
firewalls, so short of allocating 3 diffrent /48s for their own use
(customer network may be bigger as it would need to cover all users having
at least 2 IP addresses assigned depending on how large a block they sell).

Just pointing out that it is not just corporate Net Admins that will have a
stake in this decission.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 2 Dec 2008 11:30:49 -0800

There are really two separate questions here:

1) Should application developers write protocols that make assumptions as to the Source/Destination IP headers remaining constant end to end?

2) Should NAT66 be prohibited in order to allow such assumptions to be made?

And then there is the question of what NAT66 should look like if it existed which folk can take to BEHAVE.

>From the application protocol developer point of view:

* The existing network does not allow for the assumption to be made
* There is no real benefit to allowing the assumption to be made
* If I see a protocol that makes such an assumption I consider it HISTORIC [as per BCP9]
* If I see a protocol proposal that makes such an assumption I consider it BROKEN [as per PHB]

I really do not see a mass of application developers who are chomping at the bit to develop protocols with this type of assumption. There are folk who want to get around the inbound connection filtering that is a byproduct of NAT. But that is going to remain regardless. We need a means of securely communicating inbound port requests and that needs to be independent of the IP transport and IP address mapping.

Given that there is no demand from the application developers, the second question must fall. The insistence on prohibiting NAT66 is not driven by application developer concerns as has been repeatedly asserted. We know we are going to have to deal with NAT44, NAT64 and NAT46 for the foreseable future. The portion of the Internet where we can assume IPv6-6 to be supported without mapping is negligible and will not be close to a workable assumption for decades.

The reaction to NAT66 is exclusively driven by network layer concerns. It is not an architectural assumption that modern application designs exploit or could exploit if they wanted to. 

If folk want to make a network argument against NAT66 then please go away to BEHAVE. But if we have a case where the applications world is being cited as the source of a requirement and the applications world is saying that it is not so, this is the forum for that discussion.

I suggest that the only circumstance in which this discussion is worth continuing in any forum is if the opponents can identify an application where : 

1) The constant IP address assumption is required for any reason other than enabling an inbound connection to be made.
2) There is no acceptable means of implementing the requirement that does not rely on the assumption

-----Original Message-----
From: [email-masked] on behalf of Dan York
Sent: Mon 12/1/2008 5:27 PM
To: Keith Moore
Cc: 'Cullen Jennings'; 'behaveietforg WG'; 'IETF Discussion'; 'Ned Freed'; 'Eric Klein'; 'IESG IESG'; 'IAB'; 'Fred Baker (fred)'
Subject: Re: where to have the NAT66 discussion (was Re: [BEHAVE] Please movethis thread to BEHAVE mailing list ... )

.... namely:

Control.

My 2 cents,
Dan

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

---

From: Ralph Droms <[email-masked]>
Date: Tue, 2 Dec 2008 14:31:54 -0500

Iljitsch - I understand the theory behind what you're describing...in  
practice, it's a hard problem to know where all the prefixes are that  
should be changed; worse yet, it's hard to know which prefixes in  
which parts of the configuration should be replaced with new prefixes,  
and which shouldn't be changed.

In theory (where theory == reductio ad absurdum), renumbering is just  
a network and host management problem.  In practice, while SLAAC and  
prefix delegation address some (I'll wager a fairly small percentage;  
for that matter, DHCPv4 addressed the host renumbering problem years  
ago) renumbering problems, most of the places where IP addresses are  
configured were never designed with renumbering or any sort of  
"signaling" in mind, and will be very difficult to automate.

- Ralph

On Dec 2, 2008, at Dec 2, 2008,2:11 PM, Iljitsch van Beijnum wrote:

> buys you is that you don't have to renumber routers and other  
> devices that have their addresses configured staticially sitting  
> behind the NAT. But routers can receive prefixes over DHCPv6 and  
> then use those prefixes to number their stuff rather than have this  
> done by hand, so there is _very_ little need for static address  
> configuration.

---

From: Peter Dambier <[email-masked]>
Date: Tue, 02 Dec 2008 20:42:20 +0100

Hi Heith,

> responsibility, which doesn't seem like a good thing.

Maybe I am looking at the wrong protocols.

My old linux box from 1995 did for both /etc/hosts and dns try all
host addresses when telnet, ftp, tftp or html failed. I have tried
with a modern ubuntu. It still does.

I have seen both smtp and dns doing the same.

The two things that did not were ruptime and ping.

I cannot tell you about IPv6 and prefixes. I still have trouble with
my two hosts talking to each other.

> would affect diagnostic tools.

I could live with that device and I think with the suggestion of symmetric
NAT66 without touching anything but prefixes, we could make live easier
for both that core-NAT and people with a deep fear of NAT.

I guess having small transport islands with peering points and end points
could map its end points into one bucket and each of its peering point.
into its own bucket.

But obviously the out of memory problem is now moved from the routers to
the NAT.

Kind regards
Peter

- --
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [email-masked]
http://www.peter-dambier.de/
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Keith Moore <[email-masked]>
Date: Tue, 02 Dec 2008 14:41:22 -0500

Hallam-Baker, Phillip wrote:
> 1) Should application developers write protocols that make assumptions
> as to the Source/Destination IP headers remaining constant end to end?

no, that's not the question at all.

the question is whether application developers should be able to assume
that the address of a peer as viewed from one location, can be used to
reach that peer from a different location?

and the answer is clearly yes.  but NATs break that.  however, if NATs
adhere to certain rules (e.g. they support hairpinning, and their
bindings are not dependent on external peers' addresses, and they have a
STUN-like facility built in, and internal apps can explicitly request
bindings for the purpose of listening to incoming traffic) and certain
disciplines are imposed on their deployment, then applications can
obtain addresses which have these characteristics.

which might or might not be adequate overall, but it's a lot easier and
more reliable than what can be done with existing NATs in IPv4.

> 2) Should NAT66 be prohibited in order to allow such assumptions to be made?

no, that's not a well-formed question either - because it's not at all
clear that IETF prohibiting NAT66 would have any significant beneficial
effect.

the question is, what can IETF do to
(a) make NATs as sane as possible
(b) discourage NATs as much as possible and
(c) encourage such NATs as are used to be sane ones?

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 02 Dec 2008 14:46:22 -0500

> with a modern ubuntu. It still does.

my current boxes do this also.  it's not sufficient.  users will
tolerate this kind of fail over on rare occasions, but they will not
tolerate it for every click of a mouse in a web browser.

and while many apps do try multiple addresses on connection setup, most
 apps are not capable of recovering gracefully from failures once
connections are established.

(and actually it's not the case that these apps try all host addresses.
 they try all _destination_ addresses.  they do not try all combinations
of source and destination addresses.  and sometimes, in an IPv6 world,
it matters.)

Keith

---

From: David Morris <[email-masked]>
Date: Mon, 1 Dec 2008 22:05:51 -0800 (PST)

Dave Morris

---

From: Ted Hardie <[email-masked]>
Date: Tue, 2 Dec 2008 09:46:15 -0800

It's not clear to me from the above whether you mean something
like "use SCTP", something like "build ICE-like candidate selection
algorithms into the transport protocols, so that the best path gets
selected", or "run all available transports from all available flow
endpoints for as long as the flow lasts".

Care to clarify?

			Ted Hardie

---

From: Peter Dambier <[email-masked]>
Date: Tue, 02 Dec 2008 22:35:18 +0100

> as to the Source/Destination IP headers remaining constant end to end?

Applications that are started via /etc/inittab cannot change port and ip
after they are started. For security reasons they have to change user
and give up privileges. No way to reopen a priviledged port.

Applications I have seen breaking are both bind and djbdns nameservers,
sshd the ssh daemon, telnetd and ftpd and asterisk as voip server.

> 2) Should NAT66 be prohibited in order to allow such assumptions to be made?

yes :)

> existed which folk can take to BEHAVE.

A symmetric NAT would solve all problems.

Although I mentioned a simple NAT that only touches prefixes, I agree
Margaret and Fred have shown a better solution and it still would
allow symmetric NAT.

> * If I see a protocol proposal that makes such an assumption I consider

Should I see giving up privileges historic?

How about dns?

Is there a replacement?

Even zeroconf needs reliable fixed addresses.

> 
> I really do not see a mass of application developers who are chomping at
> the bit to develop protocols with this type of assumption. There are
> folk who want to get around the inbound connection filtering that is a
> byproduct of NAT. But that is going to remain regardless. We need a
> means of securely communicating inbound port requests and that needs to
> be independent of the IP transport and IP address mapping.

Should we revive uucp for email? It can securely communicate without
IP transport and IP address mapping. So can kermit for file transfer.

> 
> Given that there is no demand from the application developers, the
> second question must fall. The insistence on prohibiting NAT66 is not
> driven by application developer concerns as has been repeatedly
> asserted. We know we are going to have to deal with NAT44, NAT64 and
> NAT46 for the foreseable future. The portion of the Internet where we
> can assume IPv6-6 to be supported without mapping is negligible and will
> not be close to a workable assumption for decades.
> 
> The reaction to NAT66 is exclusively driven by network layer concerns.
> It is not an architectural assumption that modern application designs
> exploit or could exploit if they wanted to.
> 
> If folk want to make a network argument against NAT66 then please go
> away to BEHAVE. But if we have a case where the applications world is
> being cited as the source of a requirement and the applications world is
> saying that it is not so, this is the forum for that discussion.
> 
> 
> I suggest that the only circumstance in which this discussion is worth
> continuing in any forum is if the opponents can identify an application
> where :
> 
> 1) The constant IP address assumption is required for any reason other
> than enabling an inbound connection to be made.
> Cc: 'Cullen Jennings'; 'behaveietforg WG'; 'IETF Discussion'; 'Ned
> Freed'; 'Eric Klein'; 'IESG IESG'; 'IAB'; 'Fred Baker (fred)'
> Subject: Re: where to have the NAT66 discussion (was Re: [BEHAVE] Please
> movethis thread to BEHAVE mailing list ... )
> 

- --
Peter and Karin Dambier

---

From: "TJ" <[email-masked]>
Date: Tue, 2 Dec 2008 16:43:55 -0500

"However, once you decide that you MUST have private IPv6 address realms
with capability to reach the public IPv6 Internet, you have DEFINED the
architectural requirement for NAT66."

... or a proxy (which, depending on the scenario, could do some or all of
[v6-v6 | v6-v4 | v4-v6 | v4-v4] topology obfuscation), if the traffic in
question is proxy-friendly ... like HTTP ... 

/TJ

---

From: "TJ" <[email-masked]>
Date: Tue, 2 Dec 2008 16:47:34 -0500

Actually, I think SOX (and/or other 'compliance' standards) reference
RFC1918 directly, not just in spirit.

We as an industry may need to help influence those compliance requirements
to reflect current best practices, rather than solely relying on the best
way we used to do things.  Note, I am not saying we should make them rule
out NAT66 - just "pause and reflect" to see if it is a valid requirement.  
(I know some environments will say they need it regardless, and nothing
anyone says will convince them of otherwise ... for now, anyway :)   )

/TJ

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Matthew Kaufman
>Sent: Tuesday, December 02, 2008 1:28 PM
>To: james woodyatt
>Cc: [email-masked] WG
>Subject: Re: [BEHAVE] Lack of need for NAT66: Long term impact to
>application developers
>
>james woodyatt wrote:

---

From: "TJ" <[email-masked]>
Date: Tue, 2 Dec 2008 16:52:59 -0500

>This doesn't help with site renumbering problems, just endpoint

Sure it does, as long as you have time to do a "graceful" renumbering and
don't have hard-coded IPs laying around ...

/TJ

---

From: james woodyatt <[email-masked]>
Date: Tue, 2 Dec 2008 14:04:22 -0800

On Dec 2, 2008, at 10:55, Margaret Wasserman wrote:
> lines, I'd be happy to participate and contribute.  I can even offer  
> a partial draft as a starting point, which I posted today so that  
> you (and anyone else who is interested) can read it:
>

Here is the sentence in your draft where it becomes clear that my  
thinking is divergent: "The GBR will also look up the GLOC associated  
with the destination EID by checking the local cache or, if necessary,  
by performing a DNS query using the GLOC DNS record defined later in  
this document."

> [I wrote:]
>> MLDv2, etc.  Speaking as a CPE gateway developer, I can say I'd  
>> much rather have a standard like this than have to respond to  
>> marketing demands for NAT66 kludgery.  Testing an encapsulation  
>> mechanism is a lot easier than testing a full-blow NAT  
>> implementation.
>

My idea involves a significant change to host system software, which I  
think will be necessary to solve the single-prefix multi-homed site  
problem.  I think incremental deployment is possible, but difficult,  
given certain reasonable expectations.  I also think my idea may be  
incrementally deployed more easily than SHIM6.

> There are security concerns, [...]

Orthogonal, therefore separable.  Still, security is important.  I'm  
wrangling with myself over IPsec issues right now.

> ...a need for some significant DNS tie-ins...

TRIP proposes a new DNS resource record.  I'm going in a different  
direction, one that leaves DNS issues for another day.

> ...and a problem with the fact that we've suggested (in a v6ops  
> packets with unknown IPv6 extension headers...

A) It's just firewalls.
B) These are likely the same boxes that need upgrading to solve this  
problem anyway.

My proposal would certainly involve some issues specifically for  
firewalls to manage, e.g. anti-spoofing measures for flows that aren't  
using IPsec.

I think I'm going to end up writing a draft.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 03 Dec 2008 11:05:19 +1300

> RFC1918 directly, not just in spirit.

Then we need to give them an IPv6 document to reference. RFC4864 might
do it for now.

   Brian

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 2 Dec 2008 17:11:30 -0500

On Dec 2, 2008, at 5:04 PM, james woodyatt wrote:
> thinking is divergent: "The GBR will also look up the GLOC  
> associated with the destination EID by checking the local cache or,  
> if necessary, by performing a DNS query using the GLOC DNS record  
> defined later in this document."

I'll be interested to see your draft, then, because I am not sure  
where you will get the information necessary to modify the destination  
address en route if not from the DNS...

Margaret

---

From: Andrew Yourtchenko <[email-masked]>
Date: Wed, 3 Dec 2008 00:05:50 +0100 (CET)

Hi James,

On Tue, 2 Dec 2008, james woodyatt wrote:

> Here is the sentence in your draft where it becomes clear that my thinking is 
> divergent: "The GBR will also look up the GLOC associated with the 
> destination EID by checking the local cache or, if necessary, by performing a 
> DNS query using the GLOC DNS record defined later in this document."

You have endpoint A connected via a border gateway to an SP in Moscow, and 
endpoint B connected via a border gateway to another SP in Hong-Kong. A 
wants to talk to B, but it has to somehow find the location of the B's 
border gateway - because in this model neither A's nor B's endpoint 
addresses are in the core's routing table, and supposedly the only thing A 
fetches from DNS is topology-independent "B" address ?

I agree that once B gets the first packet from A, it might use the info
to forward the subsequent packets back (minus the 
spoofing concerns).

> wrangling with myself over IPsec issues right now.

If I understood your previous description, the "responder" side will 
send back the header contents it has received from the "initiator" side. 
(for simplicity sticking to the assumption that every communication is 
bidirectional).

The challenge with that would be that unless a significant 
portion of border gateways will do anti-spoofing filtering,
anyone can easily pretend to be anyone else ?

> TRIP proposes a new DNS resource record.  I'm going in a different direction, 
> one that leaves DNS issues for another day.

DNS is just a distributed hashtable that is known to have a reasonable 
performance and some desired administrative properties, which is needed to 
map a topology-independent ID onto topology-dependent ID, which is needed 
for the very first packet ?

> My proposal would certainly involve some issues specifically for firewalls to 
> manage, e.g. anti-spoofing measures for flows that aren't using IPsec.

> I think I'm going to end up writing a draft.

I'm very much interested to take a look at it.

thanks,
andrew

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 3 Dec 2008 10:55:53 +0100

On 2 dec 2008, at 20:31, Ralph Droms wrote:

> Iljitsch - I understand the theory behind what you're  
> describing...in practice, it's a hard problem to know where all the  
> prefixes are that should be changed; worse yet, it's hard to know  
> which prefixes in which parts of the configuration should be  
> replaced with new prefixes, and which shouldn't be changed.

It doesn't have to be if it's designed for this. I know a few years  
back Cisco routers had a limited capability in this area:

!
interface Ethernet1
  ipv6 address autoconfig
  ipv6 dhcp client pd dhcpv6prefix
!
interface Ethernet2
  ipv6 address dhcpv6prefix 0:0:0:A0::/64 eui-64
!

(The prefix is put in the variable "dhcpv6prefix" which is then ORed  
with the prefix 0:0:0:a0::/64 later.)

Seems to me this can easily be extended to all places where addresses  
appear.

But note that I was specifically addressing the presence vs absense of  
NAT in relationship to renumbering. All the difficult stuff is other  
people not directly under your control having pointers to your  
addresses, this is the same with or without NAT.

> most of the places where IP addresses are configured were never  
> designed with renumbering or any sort of "signaling" in mind, and  
> will be very difficult to automate.

Right, so vendors need to step up.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 3 Dec 2008 17:01:24 -0800

> a BOF before anything if any is chartered on this topic.

I look forward to the announcement about the new list. 

Tony