Subject: [nat66] RSIP and NAT66

From: james woodyatt <[email-masked]>
Date: Fri, 3 Apr 2009 13:45:16 -0700

everyone--

Would the authors of the NAT66 draft consider adding a requirement for  
NAT66 gateways to comprise the combination of the translator function  
with the IPv6-relevant functions of Realm-specific IP servers for  
symmetric NAT, c.f. RFCs 3102 and 3103?  (I don't see an immediate  
need to worry about the functions defined in RFC 3104 as long as  
address amplification can remain off the table as a goal for any IPv6/ 
NAT standard.)

I think requiring RSIP servers in the NAT66 gateway would address Dave  
Thaler's argument about Source Address Finding (SAF) as presented in  
draft-thaler-ipv6-saf, and I'm inviting the authors to respond with  
comments.  I'd be a lot less wiggy about NAT66 if it looked like RSIP  
(or its moral equivalent) might finally see the light of day.

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

---

From: Keith Moore <[email-masked]>
Date: Fri, 03 Apr 2009 16:56:50 -0400

I'm not sure RSIP is the right protocol, but I'm personally of the
opinion that any kind of standard xyNAT (for any x or y) needs to have a
well-defined, standard, signaling/control protocol.  And it needs to be
(pretty much) the same protocol for all x and y.

I'll take another look at RSIP's suitability for this in the next few days.

Keith

> symmetric NAT, c.f. RFCs 3102 and 3103?  (I don't see an immediate need
> to worry about the functions defined in RFC 3104 as long as address
> amplification can remain off the table as a goal for any IPv6/NAT
> standard.)
> 
> _______________________________________________
> nat66 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nat66

---

From: Dave Thaler <[email-masked]>
Date: Fri, 3 Apr 2009 14:56:35 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of james woodyatt
> Sent: Friday, April 03, 2009 1:45 PM
> To: NAT66 HappyFunBall
> Subject: [nat66] RSIP and NAT66
>
> everyone--
>

Hi James,

I've now had a chance to read about RSIP and also talk to Gabriel
Montenegro, one of its authors, and can answer the question you asked
me during the meeting (what's the difference between the SAF model
and RSIP).

RSIP is quite different from SAF, although it attempts to achieve
end-to-end transparency as well.  In the taxonomy of solution classes
in draft-iab-ipv6-nat, RSIP is in the second class (tunneling), whereas
NAT66 and hence SAF fall into the third class (translation).

So the differences between RSIP and NAT66+SAF are:

* RSIP uses tunneling, whereas NAT66+SAF use translation.  Tunneling
  introduces MTU issues, and has greater incentive issues since you
  get nothing until you update both hosts and gateways, whereas
  with translation you get something when you only deploy a gateway
  (the slide I showed with some happy apps and some unhappy apps).

* RSIP requires hosts to know the IP address of the gateway,
  whereas NAT66+SAF do not.  As such, failover is better with NAT66+SAF
  since the gateway is stateless and routing can just reroute traffic
  to the working exit/entry point.

* RSIP requires (and specifies) a signaling protocol between the
  host and the gateway.  A SAF mechanism may or may not have such
  a protocol.  Minimally, all that's required is that it get the
  inner/outer prefix if you're using NAT66 (or equivalent if you're
  using another IPv6 NAT mechanism).  It could get these from
  some internal entity (like a DHCPv6 server), from the NAT itself
  via a signaling protocol, or from an external entity more like
  STUN/Teredo use.  This flexibility is important to note since
  if someone deploys a NAT66 today and then wants to do a SAF
  mechanism, it means there are ways to do so that don't entail
  upgrading the NAT66 device.

Gabriel also pointed me to http://tools.ietf.org/html/draft-montenegro-aatn-nar
which was an RSIP precedessor that does allow translation (and hence
may fall into the SAF category but I still need to read it).

-Dave

---

From: james woodyatt <[email-masked]>
Date: Fri, 3 Apr 2009 16:00:35 -0700

> NAT66 and hence SAF fall into the third class (translation).

My understanding of SAF, from the presentation you gave at the 6AI  
session at IETF 74, is that it too is a tunneling solution-- just that  
the tunnel is compressed on the wire.  From the perspective of an  
application in a SAF-enabled host, it looks like there is a tunnel  
interface with an address assigned from the exterior realm.  Transport  
endpoints on the host think they are bound to their exterior realm  
address mapped by the NAT66 gateway.

>  (the slide I showed with some happy apps and some unhappy apps).

I'll grant that RSIP, as it was published, did not compress the  
tunnel, and so it would have the MTU issue that people are worrying  
about because of the inner/outer headers.  If a compliant NAT66  
gateway were also to comprise an RSIP-derived service that optionally  
permitted the tunnel to be compressed as you described in your  
presentation, then that would seem to cover all the cases, wouldn't  
it?  Hosts and/or networks could decide whether they want compressed  
or uncompressed tunnels.

The point I'm trying to raise is that we should insist that no NAT66  
gateways be deployed unless they already have the upgrade path for  
hosts to permit the restoration of transparency.  Whether the tunnels  
or compressed or not is of only secondary interest to me at this point.

>  to the working exit/entry point.

Isn't Christian Huitema's point about multi-homing relevant here?

In any event, if RSIP is extended to support tunnel compression, then  
hosts would be freed from the requirement to know the interior realm  
address of any particular NAT66 gateway; they could just send to the  
exterior realm destination address and rely on the network to forward  
traffic accordingly.  Hosts would still be at the mercy of the network  
in the case of Christian's multi-homing scenario.

>  upgrading the NAT66 device.

I'd like to see NAT66 service, if we're going to standardize one,  
start at day one with a SAF mechanism, and I think that RSIP (or  
perhaps its predecessor, NAR, if we want to ignore Christian's point  
about multi-homing) could be a fine starting point for documents to  
adopt in any working group process we might contemplate starting.

---

From: Dave Thaler <[email-masked]>
Date: Fri, 3 Apr 2009 19:20:54 -0700

> From: james woodyatt [mailto:[email-masked]]
> Sent: Friday, April 03, 2009 4:01 PM
> To: Dave Thaler
> Cc: NAT66 HappyFunBall
> Subject: Re: [nat66] RSIP and NAT66
>

That's not correct.  The SAF model is a translate-and-detranslate model.

> or compressed or not is of only secondary interest to me at this point.

The SAF model is an illustration that there's an upgrade path
without having to change the NAT66 device, but you do have to change
the host (just not at the same time).

> adopt in any working group process we might contemplate starting.

If we have the liberty of starting at day one with a SAF mechanism,
I would agree.  However, if "vendors already have NAT66" but not
SAF then I don't know if we have that liberty (again I hope we do,
and I agree with you).  NAR is perhaps one SAF mechanism worth
evaluation, and I expect there are others as well (Remi stated he
believes SAM is another SAF mechanism, for example, and I'm sure
the possibilities don't stop there).

However your main point, I gather, is that if we publish NAT66 as
an RFC, we should really simultaneously publish some SAF mechanism.
I am of the same opinion here.

-Dave

---

From: Rémi Després <[email-masked]>
Date: Sat, 04 Apr 2009 09:31:42 +0200

>> Isn't Christian Huitema's point about multi-homing relevant here?

Any reference where the point is described?

> the possibilities don't stop there).

Let me confirm here that SAM is intended in particular to restore e2e 
transparency, and to support multihoming in an ingress-filtering 
compatible way. It uses for this encapsulation with a stateless address 
mapping. It doesn't need a new protocol.

Having comments from someone having taken the time to read the posted 
draft-despres-sam-02 would be highly appreciated.

In my understanding, SAF does need encapsulation in the multihoming 
case. The question is then whether, to keep things simpler, 
encapsulation should be authorized also in the single-homing case, or 
whether it should be forbidden wherever it is feasible to avoid it. (The 
first option seems preferable for me. "Simplicity is the ultimate 
sophistication" - Leonardo da Vinci)

Last point: encapsulation can advantageously be used as a sign that e2e 
transparency is expected, even in the single-homing case. Conversely, 
absence of encapsulation can be used as an indication that address 
modification is accepted or expected: accepted if due to an inability to 
do it, which ensures backward compatibility with legacy IPv6 hosts; 
expected if due to a conscious desire for address modification, e.g. for 
some privacy reason.

> I am of the same opinion here.

Going further, why to exclude publishing an e2e transparent solution 
before a non-transparent one, if this is possible. (Of course, it can 
only be possible if tried :-))

RD

---

From: james woodyatt <[email-masked]>
Date: Sat, 4 Apr 2009 05:53:34 -0700

On Apr 4, 2009, at 00:31, Rémi Després wrote:
>> [I wrote:]

>>>> [...] NAT66 and hence SAF fall into the third class (translation).
>>>
>>> session at IETF 74, is that it too is a tunneling solution-- just  
>>> that the tunnel is compressed on the wire.  [...]
>>

I'll decline the opportunity to quibble further over the semantic  
distinction between reversible translation and tunnel compression.  I  
don't think there is as much to contrast between them as you do, but  
it's not worth arguing about.

I'll grant that the SAF model is distinct from explicit encapsulation  
models, like SAM and RSIP, in that it allows irreversible translation  
for legacy hosts until they are upgraded to support the SAF virtual  
interfaces that enable reversible translation.

> Any reference where the point is described?

<http://www.ietf.org/mail-archive/web/nat66/current/msg00200.html>

>> (Remi stated he believes SAM is another SAF mechanism, for example,  
>> and I'm sure the possibilities don't stop there).
>
> Let me confirm here that SAM is intended in particular to restore  
> e2e transparency, and to support multihoming in an ingress-filtering  
> compatible way. It uses for this encapsulation with a stateless  
> address mapping. It doesn't need a new protocol.
>
> Having comments from someone having taken the time to read the  
> posted draft-despres-sam-02 would be highly appreciated.

I've read the draft.  I don't think SAM is a SAF mechanism; it does  
not support reversible translation, i.e. what I prefer to think of as  
tunnel compression.

I also think it could use some discussion to show how SAM can be  
compatible with any-source multicast using embedded rendezvous point  
ULA addresses.  I think the two methods of overloading the IID portion  
of addresses with routing information are compatible, but I'd like to  
see a discussion of it.

I confess I am completely lost in regards to the SAM privacy option.

> case.

I think the point Christian Huitema makes in the message I referenced  
above is that NAT66 as currently proposed simply doesn't work-- and  
can't reasonably be made to work-- in the multi-homing scenario he  
outlines.  This should not be news to anyone who has ever encountered  
this same problem with symmetric IPv4 NAT multi-homing after lo these  
many eons of experience with it.  It's one of the Well-known NAT  
Problems that the NAT66 draft implicitly leaves unmitigated (where it  
defers to RFC 2993 in Section 4-- indeed, RFC 2993 doesn't go into  
much detail either: "NATs complicate the use of multi-homing by a site  
in order to increase the reliability of their Internet connectivity.").

Without some kind of encapsulation, the local realm routers between  
the hosts and the translating gateways cannot match corresponding  
forward and reverse path flows consistently to their exterior realm  
translator arrays and perverse loops can arise.  The people who  
designed RSIP and SAM understand this.  I'll be surprised if a SAF  
mechanism can be defined so that local realm SAF-aware routers can  
efficiently perform the matching required to address the problem.   
I'll be further surprised if any proposal for defining such routers  
receives no significant objections relating to the incentive problem.

This is why I think we'll *lose* if we propose a 6AI solution that  
relies on translators, even translators that MUST be augmented with a  
SAF mechanism.  I don't think we can solve this problem while avoiding  
an upgrade for hosts to support an encapsulation.

>> an RFC, we should really simultaneously publish some SAF  
>> mechanism.  I am of the same opinion here.
>
> before a non-transparent one, if this is possible. (Of course, it  
> can only be possible if tried :-))

Agreed.  If we're going to insist on publishing a losing solution for  
using translators to make perverse loops fast, can we please, at  
least, minimize the damage we do end-to-end in the process?

---

From: Christian Huitema <[email-masked]>
Date: Sat, 4 Apr 2009 08:17:53 -0700

> an upgrade for hosts to support an encapsulation.

I agree. I don't believe that a multi-homing system can work reliably without cooperation from the hosts. The good point is that we conceptually understand what is needed:

1) Isolate an edge network and its routers from changes of global addresses: this can be achieved with either a PI prefix or an ULA prefix for the edge network.

2) Hide the internal topology: this can be achieved by using a tunnel between the host and the edge router. This tunnel defines an interface for the host, combining a prefix chosen by the gateway and a unique host identifier. Only the prefix chosen for the edge router be visible outside the edge network, effectively hiding the topology. The host is aware of the external address, thus enabling publication in DNS, etc.

3) Enable multi-homing without relying on PI addresses: use several edge routers and several tunnels. Hosts that have several tunnels can see several addresses and publish them in DNS. The problem becomes the same as other forms of host multi-homing, e.g. combining a broadband connection and a 3G modem. We know that a base line works: pick a working address pair for new TCP connections using DNS, or pick a working pair for RTP connections using ICE. SHIM6, SCTP and other developments allow for harnessing multiple address pairs during a single connection.

Of course, tunnels have a cost. Two costs, in fact: transmission cost, due to overhead, and administrative cost, due to setup and management. As James points out, the transmission overhead can be reduced with header compression, so I will look at the administrative cost, and specifically at two costs, establishment and fault resolution.

Tunnels have to be established. The hosts have to discover the gateway and configure an "external" address with that gateway. The simplest solution is to use a reserved DNS name for the gateway, and then rely on either RS/RA or DHCPv6 for configuring the address. There can be more complex solutions, e.g. explicit configuration and some form of access control. The good news there is that since there is a form of management, administrators can make sure the computers in New York do not use the Internet access in London, and other such things.

Tunnels can fail. NAT can also fail. Some of the failure modes are shared: failures of links and routers in the path between host and edge router, failure of the edge router itself. Tunnel add two specific failure modes: using the wrong tunnel, and using tunnel connectivity for internal communication. Both can be addressed, by managing the edge points and by managing route selection. The good news is that tunnels can be managed explicitly, by opposition to NAT that rely on the vagaries of routing. Explicit management tends to lower the administrative cost in the long run.

So, I would suggest that we study a tunnel solution to enable topology hiding and large site multi-homing.

-- Christian Huitema

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 06 Apr 2009 14:08:07 +1200

Christian,

> So, I would suggest that we study a tunnel solution to enable topology hiding and large site multi-homing.

RFC4864 suggests a few ways to approach topology hiding
in section 4.5. I actually think the 'topology masking
router' is cleaner than tunnelling.

As for multihoming, do you have a proof-of-concept proposal
other than PI/BGP4+, LISP or SHIM6? Because we've been looking
for ten or fifteen years.

   Brian

---

From: Christian Huitema <[email-masked]>
Date: Sun, 5 Apr 2009 22:10:37 -0700

> for ten or fifteen years.

Host multi-homing works today, for some definition of work. Many PC have multiple interfaces, multiple addresses, and use them reasonably well. One thing does not work: TCP connections will not automatically migrate from a failing interface to the next. But even then, applications connections can survive if the application just retries. Many applications do that, e.g. email clients, IM clients. I use some of them every day.

What does not work so well is site multi-homing, especially if we attempt to combine multi-homing and egress filtering, or even worse if we attempt to combine both with stateful edge firewalls. In a multi-homed site, these combinations can only work if the routing is somewhat symmetric, if the two directions of traffic go through the same edge device.

My point is that if we want site multi-homing, we cannot do without engineering this routing symmetry. If we leave it to chance, then future network administrators will observe maddening failure modes, and we will have done them a great disservice. Just sticking NAT devices at various network edges is, for me, equivalent to leaving it to chance.

I believe the simplest engineering will be some form of tunneling, where internal hosts can point a packet to a specific exit point. There may well be different solutions, e.g. some forms of source-address dependent routing combined with innovative variants of the neighbor discovery protocol. But tunneling appears simpler to understand and easier to engineer.

Of course, if we implement tunneling, we do not actually need address translation. But I believe we will need tunneling for multi-homing even if we did use address translation.

-- Christian Huitema

---

From: Scott Brim <[email-masked]>
Date: Mon, 6 Apr 2009 10:35:49 -0400

Christian, I don't see the advantages of doing encapsulation from the
hosts.  Instead of going to the trouble of upgrading endpoints with
all of the capabilities to determine appropriate site egress points
and monitor their liveness so the endpoint's traffic only exits from
one site egress point, why not just upgrade the endpoints with a
locator/identifier separation mechanism so the endpoints can use all
egress points?  This will also make it possible for endpoints to take
advantage of being multi-homed across multiple domains.  This is
independent of whether we need NAT66 for the site.

Scott

---

From: Scott Brim <[email-masked]>
Date: Mon, 6 Apr 2009 11:24:03 -0400

Excerpts from Christian Huitema on Sun, Apr 05, 2009 10:10:37PM -0700:
> My point is that if we want site multi-homing, we cannot do without
> engineering this routing symmetry. If we leave it to chance, then
> future network administrators will observe maddening failure modes,
> and we will have done them a great disservice. Just sticking NAT
> devices at various network edges is, for me, equivalent to leaving
> it to chance.

What failure modes?  IP routing will be as deterministic (ahem) as it
is now.  E2E session continuity is at risk, but session continuity in
the face of massive routing changes is not, as far as I know, a goal
in NAT66.  The only truly difficult scenario is the one Fred Baker
described where traffic could yoyo back and forth.  I could see using
routing headers.

Scott

---

From: Rémi Després <[email-masked]>
Date: Mon, 06 Apr 2009 17:43:53 +0200

> <http://www.ietf.org/mail-archive/web/nat66/current/msg00200.html>

Thanks for the ref.

 > I've read the draft.  I don't think SAM is a SAF mechanism; it does not
> support reversible translation, i.e. what I prefer to think of as 
> tunnel compression.
True.
Tunnel compression could be added to SAM if the complexity/new-service
is found favorable. But at least in the multi-homing case with multiple
  CPEs tunnels are AFAIK unavoidable.
> ULA addresses.  I think the two methods of overloading the IID 
> portion of addresses with routing information are compatible, but I'd
>  like to see a discussion of it.
> 
If rendez-vous points are SAM capable and addressed in the global space,
I don't see why they wouldn't work but, agreed, this justifies specific
a specific discussion.

> I confess I am completely lost in regards to the SAM privacy option.
It's clear that that my first text on it needs a lot of clarification
and simplification. Apologies for having not done more of these yet.

The main idea is as follows.
- CPEs exercise a reversible translation of subnet identifier and port
number between internal packets and external packets.
- Parameters of this reversible translation are communicated to hosts.
- Hosts can then do the same translation of between internal packets and
application APIs.

Thus:
- Internal routing can be performed with untranslated subnet numbers
and, in the case of port extended IPv4, on untranslated ports.
- Addresses and ports seen by applications are those that traverse the
global Internet.

Which algorithms to use for the reversible translation could be seen at
this stage as a secondary point. (Gabor Bajko, for example, pointed out
that a modulo n multiplication by an odd number would be pushing too far
the trade off between simplicity and functional effectiveness in the
direction of simplicity, which I accept.)

> outlines.
With SAM, there are combined parameters for mapping and encapsulation.

In Fred's example, Alice uses her source address the ISP prefix of which 
is that of the Bob's root SAM, rule 2 of page 9 in draft-despres-sam-02 
is such that the local destination must be Bob's local address.

In Christian's example, the same rule is such that Carol sends its SYN 
via DAN, it must be with a global source address that includes the ISP 
prefix of Dan. Alice's SYN ACK will therefore not return via Bobby.

In my understanding, this is precisely where SAM solves an otherwise 
unsolved multihoming problem.

>> Going further, why to exclude publishing an e2e transparent 
>> solution before a non-transparent one, if this is possible. (Of 
>> course, it can only be possible if tried :-))
> 

Thanks.

RD

---

From: Christian Huitema <[email-masked]>
Date: Mon, 6 Apr 2009 09:16:34 -0700

> described where traffic could yoyo back and forth.  I could see using

The failure mode happens in the 4-ways criss-cross scenario, which I described in a previous message:
<http://www.ietf.org/mail-archive/web/nat66/current/msg00200.html>.

-- Christian Huitema

---

From: james woodyatt <[email-masked]>
Date: Mon, 6 Apr 2009 10:36:42 -0700

> james woodyatt  -  le (m/j/a) 4/4/09 2:53 PM:
[...]
>> not support reversible translation, i.e. what I prefer to think of  
>> as tunnel compression.
>
> True.  Tunnel compression could be added to SAM if the complexity/ 
> new-service is found favorable. But at least in the multi-homing  
> case with multiple CPEs tunnels are AFAIK unavoidable.

The only way to avoid it would be to upgrade all the IPv6 routers in  
the path traversed between hosts and realm gateways to be aware of the  
reversible translation (i.e. tunnel compression) mechanism in use.   
That approach, while technically plausible I think, would not be  
terribly pragmatic.

[...]
>> I think the point Christian Huitema makes in the message I  
>> referenced above is that NAT66 as currently proposed simply doesn't  
>> work-- and can't reasonably be made to work-- in the multi-homing  
>> scenario he outlines.
>
> In Fred's example, Alice uses her source address the ISP prefix of  
> which is that of the Bob's root SAM, rule 2 of page 9 in draft- 
> despres-sam-02 is such that the local destination must be Bob's  
> local address.
>
> In Christian's example, the same rule is such that Carol sends its  
> SYN via DAN, it must be with a global source address that includes  
> the ISP prefix of Dan. Alice's SYN ACK will therefore not return via  
> Bobby.
>

I think RSIP solved this problem, too, but differently.

Where SAM innovates is by encoding all the routing and tunnel endpoint  
configuration into the IPv6 addresses, thereby avoiding the need for a  
client-server session at the expense of making it require IPv6 in the  
outer tunneling layer.

RSIP is designed to permit both IPv4 and IPv6 at both inner and outer  
tunneling layers, but at the expense of requiring an explicit client- 
server protocol between hosts and realm gateways.

Which of the two is better is a tough call for me to make right now.

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Tue, 7 Apr 2009 10:44:32 -0400

If NAPT66 creeps into the picture (with a P) - we might be able to
implement a SAF mechanism (or its equivalent) by allowing hosts to query
the NAPT66 box about its bindings through some protocol.  If hosts knew
what their external binding was, they would be able to reverse the
translation, restoring transparency - however, this may not be as
straight-forward as it is with the mechanism proposed for NAT66
(referring to Margaret's draft) - especially if the host has to reverse
ALG's.

- Wes 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of james woodyatt
Sent: Friday, April 03, 2009 4:45 PM
To: NAT66 HappyFunBall
Subject: [nat66] RSIP and NAT66

everyone--

amplification can remain off the table as a goal for any IPv6/ NAT
standard.)

---

From: Rémi Després <[email-masked]>
Date: Wed, 08 Apr 2009 10:36:37 +0200

james woodyatt  -  le (m/j/a) 4/6/09 7:36 PM:
>> True.  Tunnel compression could be added to SAM if the 
>> complexity/new-service is found favorable. But at least in the 
>> multi-homing case with multiple CPEs tunnels are AFAIK unavoidable.
> 
> The only way to avoid it would be to upgrade all the IPv6 routers in the 
> path traversed between hosts and realm gateways to be aware of the 
> reversible translation (i.e. tunnel compression) mechanism in use.  That 
> approach, while technically plausible I think, would not be terribly 
> pragmatic.

Yes. Systematic encapsulation has for it its pragmatic simplicity.
>> which is that of the Bob's root SAM, rule 2 of page 9 in 
>> draft-despres-sam-02 is such that the local destination must be Bob's 
>> local address.
>>

The RSIP solution has in my understanding many more points for further 
study than SAM, but you are right: it does deal with the outgoing 
gateway selection problem. Thanks.

> tunneling layers, but at the expense of requiring an explicit 
> client-server protocol between hosts and realm gateways.
> 

IMHO, a key is whether we wish to choose simplicity when and where it is 
possible, leaving for possible later steps more complex mechanisms that 
deal with more complex scenarios. (I call this "Functional Progressiveness".

RSIP necessitates a new TBD protocol and, using upon-request and 
temporary mappings, has the various associated problems (how and when to 
reclaim mappings; what if a node is turned off while having been 
assigned some mapping etc.) None of this is needed with SAM which, based 
on stateless mappings, just needs a few parameters to be advertised to 
branch nodes (in DHCP, RAs, DNS-SD, and/or others (?)).

The choice could then be:
- are we interested in studying SAM now, for what it can offer rapidly, 
thus letting examination of what a revised RSIP might add to it for a 
later time?
- OR do we prefer to insist that dynamic mappings should be included 
from the outset, even for all simple cases where stateless mappings are 
sufficient?

Regards,

RD

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 8 Apr 2009 11:50:11 -0700

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Christian Huitema
> Sent: Monday, April 06, 2009 9:17 AM
> To: Scott Brim
> Cc: NAT66

The first thing that struck me is that if the hosts in a network 
are only doing client-initiated connections -- for example because 
of a separate security policy -- that network avoids the 4-ways 
criss-cross complication.  That said, I believe I have a solution:

The 4-way criss-cross should be solvable by providing two ULAs to
every host -- one ULA for each NAT66 egress.  The host would then
reply (send a TCP SYN+ACK) using the same ULA as the incoming 
request (TCP SYN).  The enterprise network could do source-based 
routing to steer the reply traffic towards the NAT66 associated 
with the ULA, preventing a criss-cross.  This is similar 
to Dave Thaler's SAF approach using virtual interfaces he 
presented in 6AI.

This retains address independance but it does complicate the 
enterprise's network because each host gets "n" ULAs, where 
"n" is the number of ISPs.  

-d

---

From: Dan Wing <[email-masked]>
Date: Wed, 8 Apr 2009 11:50:11 -0700

-d

---

From: Rémi Després <[email-masked]>
Date: Mon, 13 Apr 2009 10:31:52 +0200

> "n" is the number of ISPs.  

With SAM, don't need 2 ULAs to get 2 global addresses.

SHIM6 and SCTP can use the 2 global addresses. Global packets are 
encapsulated in local packets in which addresses contain the local ULA.

Regards,

RD

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Apr 2009 14:35:53 +1200

> "n" is the number of ISPs.  

Which would destroy one of the nice points about ULAs, i.e. no
need to touch them when you add or drop an ISP.

It seems to me that we need to solve the exit selection problem,
and in a broader context than just NAT66.

    Brian

    Brian