Subject: Re: [nat66] Fwd: I-D Action:draft-iab-ipv6-nat-00.txt

From: Roger Marquis <[email-masked]>
Date: Mon, 23 Mar 2009 11:38:08 -0700 (PDT)

Keith Moore wrote:
>> That's true of IPv4/IPv4 NATs. It's not true of NAT66 - explicitly.
> Not clear.  Any time it becomes necessary to use a particular v6 address
> from a particular scope in order to reach a peer, reachability is
> harmed.  Any time a NAT creates an alias for an existing address that,
> if used, might cause pessimal routing of traffic, reachability is harmed.

Exactly, and that's one of the two main reasons NAT is so popular.
Residential and commercial network owners and operators don't want their
internal hosts to be directly reachable.  This is the business case that
IPv6 must meet before it has any chance of being widely adopted.

Roger Marquis

---

From: Keith Moore <[email-masked]>
Date: Mon, 23 Mar 2009 12:03:37 -0700

Roger Marquis wrote:
> internal hosts to be directly reachable.  

perhaps not, but they want their favorite apps to work even if those
apps require that those hosts be directly reachable.

in other words, people want what they want, and the vast majority of
those people don't understand the extent to which things like "whether
their hosts are directly reachable" impacts what they want.

Keith

---

From: Fred Baker <[email-masked]>
Date: Mon, 23 Mar 2009 12:18:33 -0700

> internal hosts to be directly reachable.

That's a fairly sweeping statement. At my company, there are a huge  
number of hosts that we don't want to be externally accessible as  
servers but which we allow to be clients of various sorts. At the  
network layer, the difference between a request and response is not  
visible.

One can certainly make one's hosts unreachable. One can not advertise  
them in DNS, one can enumerate them using a prefix that isn't routed  
outside (and perhaps isn't even routed to the DMZ), and so on. Oh yes,  
there exist filters, which are the usual strategy of choice - stateful  
firewalls act as diodes, allowing session initiation in one direction  
but not the other. If someone doesn't want to authorize external  
access to a host, that's not very hard to enforce. That is not the  
purpose - and explicitly not a feature - of NAT66. Prophylactic  
security, which has all of the issues and benefits of contraceptive  
prophylactics, is quite separate.

I think the question Keith and others are asking is not whether a  
system is reachable when they are not authorized to reach it. The  
dreamers in the crowd might like to ignore that, but those of us who  
live in the real world can ignore them. The question is the  
reachability of systems that one is authorized to reach.

Keith is arguing that end to end addressing is required to implement  
that. My point is that the exact number of the address is less  
important than the ability to identify the host, given that the  
application itself is not trying to know something about network layer  
addressing.

---

From: Keith Moore <[email-masked]>
Date: Mon, 23 Mar 2009 12:47:06 -0700

Fred Baker wrote:
> but not the other. If someone doesn't want to authorize external access
> to a host, that's not very hard to enforce. That is not the purpose -
> and explicitly not a feature - of NAT66. Prophylactic security, which
> has all of the issues and benefits of contraceptive prophylactics, is
> quite separate.
> 
> I think the question Keith and others are asking is not whether a system
> is reachable when they are not authorized to reach it. The dreamers in
> the crowd might like to ignore that, but those of us who live in the
> real world can ignore them. The question is the reachability of systems
> that one is authorized to reach.
> 
> that. 

I'm arguing that applications need to be able to accept traffic at
global addresses in order to implement that reliably and without a lot
of additional complexity.  The app doesn't care what the address looks
like on the wire, but it does (ideally) want the address to be the same
for each of it its (current and potential) peers.  That's by far the
simplest model for an application to deal with.

Whenever a NAT (any kind of NAT) provides additional addresses at which
an application can accept traffic (and if there's any bias at all such
that some of those addresses work better than others for a given peer),
that increases the burden on the application, because it has to make a
good choice about which source and destination addresses to use.  (The
burden is even worse for P2P apps.)   In the extreme case this is about
reachability, in less extreme cases it's about performance and
reliability, but it's more-or-less the same issue.

> My point is that the exact number of the address is less important
> than the ability to identify the host, given that the application itself
> is not trying to know something about network layer addressing.

The application doesn't care about the exact number of the address.
However it might care that the same address work for all of its peers,
or that if it opens multiple connections to a peer that they all
originate at the same address, or that each of its peers to which it has
an open connection will see the same source address, etc.

Keith

---

From: Fred Baker <[email-masked]>
Date: Mon, 23 Mar 2009 13:29:08 -0700

> simplest model for an application to deal with.

Hmm. There goes mobile IP.

Tell me this. In the following picture

                                       +-----+  |
                                       |ISP 1|--+
                                       | DMZ |  |
                                      /+-----+  |
                                     /          |
                                    /  +-----+  | +---+
         +---+                     /   |ISP 2|--+-+ B |
         | A +----  The Internet  -----+ DMZ |  | +---+
         +---+                     \   +-----+  |
                                    \           |
                                     \ +-----+  |
                                      \|ISP 3|--+
                                       | DMZ |  |
                                       +-----+  |

B has three AAAA resource records giving it three different addresses.  
A can easily select one by whatever algorithm it is using and use it.  
As far as B knows, the one A selected was its ULA.

It seems like we accomplished your goal....?

> reliability, but it's more-or-less the same issue.

You're aware that it doesn't take a NAT to provide multiple addresses  
- all it takes is a multihomed host. Right? Does a multihomed host  
have the issues you are concerned about? If not, why not?

> an open connection will see the same source address, etc.

OK. So what you told me was, perhaps, that hairpinning is a concern.  
 From my perspective, if a host B' in B's network tries to use one of  
its external addresses rather than preferring the address available  
behind the DMZ, it didn't correctly execute the algorithm in RFC 3484,  
which calls for it to prefer the address most similar to its own.

---

From: Ted Hardie <[email-masked]>
Date: Mon, 23 Mar 2009 13:42:08 -0700

>which calls for it to prefer the address most similar to its own.

I note that RFC 3484 refers to site-local, rather than ULAs.  Is there work
done/underway to revise the algorithm to explain whether ULA maps exactly
to site-local?  Given that ULAs allowed for "informed consent" routing among
adult networks, it seems more like it gets treated/should be treated
exactly as other global scope addresses, with possibly impaired reachability. 
But, as I said,  I am not all sure I understand how to map my previous
understandings of scope onto this work.

				Ted

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 23 Mar 2009 13:44:07 -0700

Ted Hardie a écrit :
> to site-local? 

there is a design team working on updating RFC3484. There will be an
update of this work presented during 6man this week.

Marc.

> Given that ULAs allowed for "informed consent" routing among
> _______________________________________________
> nat66 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nat66

-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN news service: http://reeves.viagenie.ca

---

From: Ted Hardie <[email-masked]>
Date: Mon, 23 Mar 2009 13:51:13 -0700

>update of this work presented during 6man this week.

Is there a draft pointer?
				Ted

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 23 Mar 2009 13:56:11 -0700

> Is there a draft pointer?

draft-arifumi-6man-rfc3484-revise-00.txt
draft-chown-addr-select-considerations-02.txt

Marc.

---

From: Fred Baker <[email-masked]>
Date: Mon, 23 Mar 2009 14:03:58 -0700

draft-arifumi-6man-rfc3484-revise

---

From: Keith Moore <[email-masked]>
Date: Mon, 23 Mar 2009 14:05:15 -0700

> Hmm. There goes mobile IP.

mobile IP, NATs, multiple prefixes advertised for a v6 network, multiple
active interfaces for a host - all of these make life more complicated
for applications.

(you'd hear more screaming about mobile IP from apps developers if it
were more widely deployed.  you'd also hear screaming about VPNs from
apps developers if it weren't common to shut down all other paths to a
host whenever it has a IPsec link to a VPN.)

> B has three AAAA resource records giving it three different addresses. A
> can easily select one by whatever algorithm it is using and use it. As
> far as B knows, the one A selected was its ULA.
> 

sort of.

B thinks its traffic arrived at a ULA, but B presumably can't use that
ULA as a referral address as it won't work everywhere, and B really has
no idea whether the ULA is reachable by any particular (current or
potential) peer.  That might be fine as long as (a) B can obtain a
sufficiently stable referral address that works from anywhere (modulo
policy), (b)  that mechanism for obtaining a referral address works for
any application that needs to do referrals, (c) this mechanism works
from anywhere in the network that isn't using stable, global addresses,
not just from places that are using this particular kind of setup.

(in short, we need to define a universal way for apps to do referrals
that works no matter where the peers are.)

A might see a view of B that has 3 (or fewer) addresses.  This is not a
big deal, provided all of those external addresses are highly reliable,
equally usable, and sufficiently stable, so that A's choice of which
external address rarely matters.  But those are important conditions
that are not always met in practice.

> You're aware that it doesn't take a NAT to provide multiple addresses -
> all it takes is a multihomed host. Right? Does a multihomed host have
> the issues you are concerned about? If not, why not?

yes, it does.  and it's one reason that multihomed hosts were rarely
used in IPv4 - they tended to break things.

> OK. So what you told me was, perhaps, that hairpinning is a concern.

hairpinning is certainly necessary.

> From my perspective, if a host B' in B's network tries to use one of its
> external addresses rather than preferring the address available behind
> the DMZ, it didn't correctly execute the algorithm in RFC 3484, which
> calls for it to prefer the address most similar to its own.

I have never considered RFC 3484 workable.  It might almost be
reasonable as a default behavior for APIs,  but it's clearly not
reasonable to insist that all hosts/apps behave that way.

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 23 Mar 2009 14:08:27 -0700

> understandings of scope onto this work.

I don't think a host or app can make assumptions about what a ULA means.
   It's not inherently a "site" local or private address.  There are
cases where a ULA will work better than a global address, and there are
cases where the opposite is true.  And the meaning of "better" depends
not only on the topology of the network seen by the host but also on the
needs of an application.  (e.g. is it better to use an address that is
stable, or to have an address that is globally reachable in referrals?
even then, an app cannot reasonably assume that a ULA is more stable
just because it's a ULA.)

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Mar 2009 10:09:45 +1300

> done/underway to revise the algorithm to explain whether ULA maps exactly

ULAs are specifically defined to have global scope, since they can legitimately
be used off-site for VPN routing with other consenting sites; the rule is
that they must not be routed on the public Internet.

So, no, they specifically do not map onto site local and it is normal
that RFC3484 doesn't distinguish them from other forms of globally
scoped addres.

> understandings of scope onto this work.

Well, what VPNs tell us is that the 'concentric circles' view of link,
site and global scope is not an accurate model of the real world, and
ULAs make this inconvenient truth hard to ignore.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Mar 2009 10:14:10 +1300

Roger,

On 2009-03-24 07:38, Roger Marquis wrote:
...

> internal hosts to be directly reachable.  

Have you read RFC4864?

   Brian

---

From: Fred Baker <[email-masked]>
Date: Mon, 23 Mar 2009 14:26:02 -0700

On Mar 23, 2009, at 2:05 PM, Keith Moore wrote:

> ULA as a referral address as it won't work everywhere,

http://tools.ietf.org/html/draft-wing-behave-nat64-referrals
   "Referrals Across a NAT64", Dan Wing, 4-Mar-09,
   <draft-wing-behave-nat64-referrals-00.txt>

---

From: james woodyatt <[email-masked]>
Date: Mon, 23 Mar 2009 14:33:23 -0700

On Mar 23, 2009, at 14:09, Brian E Carpenter wrote:
>> OK. So what you told me was, perhaps, that hairpinning is a  
>> concern.  From my perspective, if a host B' in B's network tries to  
>> use one of its external addresses rather than preferring the  
>> address available behind the DMZ, it didn't correctly execute the  
>> algorithm in RFC 3484, which calls for it to prefer the address  
>> most similar to its own.
>

They must not be routed in the default-free zone.  That's not the same  
as the public Internet.  We can certainly expect the public Internet  
to contain some routes for ULA prefixes; they just won't ever appear  
in the default-free zone.

I recognize the distinction is subtle, but it's not without relevance  
to the larger discussion at hand: namely, the effect of NAT66 on the  
utility of address referrals, which is where the hairpinning concern  
will arise.

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

---

From: Fred Baker <[email-masked]>
Date: Mon, 23 Mar 2009 14:39:27 -0700

> hairpinning is certainly necessary.

OK.

The implications of hairpinning are...

<aside>
For those of us who don't know what "hairpinning" is, the term derives  
from telephony. There are cases where a call goes down a trunk to some  
kind of translator or interchange, but instead of going across the  
exchange point, it turns around and goes right back the way it came.  
The same thing can happen in IP.

In this context, it would relate to a system inside a network using an  
address appropriate to systems outside the network. The datagram goes  
to the DMZ, but instead of crossing it and going out of house, it  
turns around and goes back in.
</aside>

The simplest way to accomplish this in NAT66 will be for the DMZ to  
hand it upstream to its ISP. In doing so, it converts the source  
address to the DMZ's prefix. The ISP PE router turns it around and  
sends it back, resulting in the translation of the destination  
address. The target system's reply goes through a similar route.

The more appropriate case, called for in RFC 4787, might be to  
recognize that this is about to happen and instead of changing the  
source address, change the destination address. This results in the  
target seeing a datagram from/to the ULA. One direction goes through  
the DMZ, but the replies are direct.

IMHO, an even more appropriate solution would be to drop the datagram  
and reply "Destination Unreachable", to cause the originating host to  
do a better job of address selection. If the system has both an  
internal and an external address, I don't see the argument for not  
expecting the peer to use the appropriate one.

The draft states that hairpinning is required, but doesn't go into how  
it is done.

    NAT66 devices MUST support hairpinning behavior, as defined in the
    NAT Behavioral Requirements for UDP document [RFC4787].  This means
    that when a NAT66 device receives a packet on the internal interface
    that has a destination address that matches the site's external
    prefix, it will translate the packet and forward it internally.   
This
    allows internal nodes to reach other internal nodes using their
    external, global addresses when necessary.

    o  Added hairpining requirement and discussion of applicability of
       other NAT behavioral requirements.

---

From: Keith Moore <[email-masked]>
Date: Mon, 23 Mar 2009 15:48:24 -0700

>   <draft-wing-behave-nat64-referrals-00.txt>

I'm glad to see someone is thinking about this.  However, merely being
able to do referrals across nat64 for SIP and Bittorrent is not
sufficient.  It needs to work for every kind of NAT, and for anything
else that blocks referrals other than for policy reasons, and for any
kind of app that wishes to do referrals.

Of course we can't expect deployed boxes to magically upgrade
themselves, so what I'm talking about is the desired end-state.  The
point is that if we're going to have NATs of any kind in the
architecture, we need to define a way for the apps to do referrals in
spite of those NATs.  It's not sufficient to provide a piecemeal
solution that works only for specific kinds of NATs or specific apps.

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 23 Mar 2009 16:04:17 -0700

Fred
> The simplest way to accomplish this in NAT66 will be for the DMZ to hand
> it upstream to its ISP. In doing so, it converts the source address to
> the DMZ's prefix. The ISP PE router turns it around and sends it back,
> resulting in the translation of the destination address. The target
> system's reply goes through a similar route.
> 
> The more appropriate case, called for in RFC 4787, might be to recognize
> that this is about to happen and instead of changing the source address,
> change the destination address. This results in the target seeing a
> datagram from/to the ULA. One direction goes through the DMZ, but the
> replies are direct.

Maybe I missed it but I don't see how RFC 4787 imposes a burden on hosts
or apps to do address selection.

> and reply "Destination Unreachable", to cause the originating host to do
> a better job of address selection. 

See, now you're asking the host or the app to do the network's job.

The apps are supposed to send packets to their peers without worrying
about how to get them there.  The network is supposed to make a best
effort to deliver them, modulo policy.

As soon as the network says "sorry, I won't deliver this because you
didn't use the right (source or destination) address for this realm" ...
it has abandoned the "best effort" model and the separation of function
between the host and the network.  And the implications of that are
huge.  e.g.

- It forces hosts and apps to try to be aware of addressing realms, and
to make decisions about how to not only route packets but how to do
referrals to peers which may or may not be in the same realms as they are.

- Because the host or app doesn't know why the traffic is blocked, it
encourages hosts and apps to interpret such restrictions as network
failures or damage (even if they're caused by policy) and route around
them.

etc.

> If the system has both an internal
> and an external address, I don't see the argument for not expecting the
> peer to use the appropriate one.

1. Because apps in general don't know which addresses are appropriate,
and "appropriate" is highly dependent both on the needs of the
applications and the way in which those addresses are used.  The fact
that an address has a ULA prefix doesn't mean that it's somehow more
appropriate than a global address.

2. Because address selection for referrals is even harder than address
selection for connection establishment.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Mar 2009 12:53:31 +1300

Hi Fred,

On 2009-03-24 10:39, Fred Baker wrote:
...
>    prefix, 

s/the site's external prefix/one of the site's external prefixes/

Since this is IPv6, there might be more than one, unless we plan
a rule that one NAT66 can only support one external prefix, in
which it's

s/the site's external prefix/the site's external prefix to which the
NAT66 in question is connected/

   Brian

---

From: Fred Baker <[email-masked]>
Date: Mon, 23 Mar 2009 17:41:45 -0700

> See, now you're asking the host or the app to do the network's job.

Actually, no. I am asking the host to do it's job.

RFC 3484, whatever its issues may be, makes it the host's job to  
select an address pair that makes sense. Among other things, it asks  
the system opening the session to look at the list of addresses  
advertised in DNS for its target, compare them to its own set of  
addresses, and choose the address pair that simultaneously minimizes  
scope and maximizes the length of the matching prefix.

I'm simply suggesting that if the device has the option of hairpinning  
and the option of not hairpinning, not hairpinning makes the most  
sense. Therefore it is reasonable for the network to advise the host  
to try a different address pair.

---

From: james woodyatt <[email-masked]>
Date: Mon, 23 Mar 2009 17:56:33 -0700

> the DMZ, but the replies are direct.

That can work for UDP, in those applications that don't care so much  
about source and destination addresses for matching session endpoints,  
but it doesn't work for connection-oriented transports, e.g. TCP,  
SCTP, DCCP, etc.  For those transports, hairpinning requires the NAT  
to translate both the source and destination addresses.

---

From: Keith Moore <[email-masked]>
Date: Mon, 23 Mar 2009 18:02:12 -0700

Fred Baker wrote:
> RFC 3484, whatever its issues may be, makes it the host's job to select
> an address pair that makes sense. 

STRONGLY disagree.  The title says "Default".  That implies that it's
not the only way to do address selection.  And as a practical matter, an
algorithm like that in RFC 3484 that is based entirely on prefix
matching can never work well for all cases even for client-server apps
and it certainly can't work well for apps that do referrals.

3484 would never had gotten consensus had it claimed to be mandatory, as
it was clearly not workable as a general solution.

> Among other things, it asks the system opening the session to look at
> the list of addresses advertised in DNS

That assumes that the "system" is getting its addresses from DNS.

> and the option of not hairpinning, not hairpinning makes the most sense.

The most sense for whom?  Certainly not for the app, nor for the user of
the app, nor for the vendor of the app who has to get his app working in
dysfunctional environments.

> Therefore it is reasonable for the network to advise the host to try a
> different address pair.

Only if you don't care about the network actually supporting applications.

Keith

---

From: Fred Baker <[email-masked]>
Date: Mon, 23 Mar 2009 18:12:15 -0700

Or perhaps to force the host to use an address pair that doesn't need  
translation, given that such exists?

On Mar 23, 2009, at 5:56 PM, james woodyatt wrote:

>> target seeing a datagram from/to the ULA. One direction goes  
>> through the DMZ, but the replies are direct.
>
> about source and destination addresses for matching session  
> endpoints, but it doesn't work for connection-oriented transports,  
> e.g. TCP, SCTP, DCCP, etc.  For those transports, hairpinning  
> requires the NAT to translate both the source and destination  
> addresses.
>
>
> --

---

From: Keith Moore <[email-masked]>
Date: Mon, 23 Mar 2009 18:19:45 -0700

> translation, given that such exists?

and thus prevent the host's peer from doing referrals to any host
outside of the scope of the ULA, at least absent significant revision to
all protocols that do referrals?

Keith

---

From: Fred Baker <[email-masked]>
Date: Mon, 23 Mar 2009 18:24:33 -0700

On Mar 23, 2009, at 6:02 PM, Keith Moore wrote:

>> select

Well, yes. The host could select addresses another way. It remains the  
host's job to pick addresses that make sense.

> dysfunctional environments.

Well, would you like the network to select the addresses for the host?  
If so, I have a tool nearby that would enable me to overwrite the  
addresses the host uses. Except you don't seem to like that either.

So whatever I do, I'm wrong and you're right. That's not much of a  
conversation. Would you like to have a conversation, or would you like  
to continue in this mode of brickbats?

I for one am through discussing this aspect. I don't think it is  
helping to clarify requirements.

---

From: james woodyatt <[email-masked]>
Date: Mon, 23 Mar 2009 18:47:56 -0700

>  <draft-wing-behave-nat64-referrals-00.txt>

An interesting thing about this document: it doesn't discuss P2PSIP.   
I went looking to see how P2PSIP would be affected by NAT66, and the  
answer seems to me that P2PSIP uses TURN for doing NAT traversal (see  
the highly amusing <http://tools.ietf.org/html/draft-ietf-behave-turn-ipv6 
 >), but its bootstrap service is defined as a SIP registrar and  
proxy, which depends on DNS64 to achieve the referral transparency  
described in the draft Fred mentions.

I've a feeling that NAT66 complicates the bootstrap process for P2PSIP  
overlays, but I'm not sure how.  I don't think I see how P2PSIP  
bootstrap servers can be deployed behind NAT66 without tightly coupled  
coordination with the NAT, and I wonder about Fred's ideas about  
hairpin denial in that case...

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 23 Mar 2009 18:58:04 -0700

> -----Original Message-----
> From: james woodyatt [mailto:[email-masked]] 
> Sent: Monday, March 23, 2009 6:48 PM
> To: [email-masked] Discussion
> Cc: Dan Wing
> Subject: Re: [nat66] Fwd: I-D Action:draft-iab-ipv6-nat-00.txt
> 
> the highly amusing 
> <http://tools.ietf.org/html/draft-ietf-behave-turn-ipv6>), 
> but its bootstrap service is defined as a SIP registrar and  
> I've a feeling that NAT66 complicates the bootstrap process 
> for P2PSIP overlays, but I'm not sure how. 

The P2PSIP device would need to know its publicly-routable
IPv6 address.  Very much like with an IPv4 NAT (needs to 
know publicly-routable IPv4 address) or NAPT (needs to know
publicly-routable IPv4 address and port).

> I don't think I see how P2PSIP  
> coordination with the NAT,

http://tools.ietf.org/html/draft-thaler-ipv6-saf describes
this in some detail.

> and I wonder about Fred's ideas about  

Hairpinning of media traffic is avoided by ICE and RFC3484
address preference rules.  I know P2PSIP uses ICE for its 
media traffic.

I doubt P2PSIP prevents hairpinning of the P2PSIP signaling
traffic for IPv4 NATs.  So it is unlikely that it prevents
hairpinning of P2PSIP signaling traffic in the presence of
an IPv6 NAT (NAT66).  But I am not well-versed in P2PSIP;
perhaps it does some sort of optimization.

-d

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 23 Mar 2009 22:44:48 -0700

On Mar 23, 2009, at 4:53 PM, Brian E Carpenter wrote:
> Since this is IPv6, there might be more than one,

I agree.  Thanks for the correction.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 23 Mar 2009 22:49:41 -0700

> the DMZ, but the replies are direct.

I think that your second option is the right choice.  I agree that the  
NAT66 draft does not currently say this, and it should probably be  
updated to do so.
>
> IMHO, an even more appropriate solution would be to drop the  
> datagram and reply "Destination Unreachable", to cause the  
> originating host to do a better job of address selection. If the  
> system has both an internal and an external address, I don't see the  
> argument for not expecting the peer to use the appropriate one.

I think that hairpinning is supposed to handle the case where a node  
only has a global address (perhaps from the DNS?) for a host that is  
also behind the same NAT.  While I agree that a host should choose the  
local address if it is known, I think that will happen automatically  
via longest prefix match.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 23 Mar 2009 22:58:17 -0700

Hi James,

> requires the NAT to translate both the source and destination  

Your right.  Translation of both addresses is needed, effectively  
translating in both the outbound and inbound directions, so that the  
return packets will go back through a NAT66 box to be translated back  
again.

Margaret

---

From: Rémi Després <[email-masked]>
Date: Tue, 24 Mar 2009 05:19:47 -0700

Margaret Wasserman  -  le (m/j/a) 3/23/09 10:58 PM:
>> requires the NAT to translate both the source and destination addresses.
Also, ingress filtering requires, in my understanding, that what you 
send could return to you if source and destination would be permuted.
> return packets will go back through a NAT66 box to be translated back 
+1 for this choice.

RD

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 24 Mar 2009 14:10:56 -0700

WIth my P2PSIP individual contributor hat on ....

Interesting question and we should go and check the details on this. I  
have no idea where you are getting the idea that the  "bootstrap  
service is defined as a SIP registrar and proxy" - the RELOAD  
bootstrap does not  have anything to do with SIP.

The design of RELOAD was such that it would work fine in v4, or v6, or  
dual stack, or various nat 4 or 6 related situations. It uses ICE to  
set up most the connections and ICE is pretty good at  taking a bunch  
of addresses and seeing if they work. The bootstrap does not use SIP  
registrar so we should dig down on that and make sure there is no  
confusion - I apologize in advance for confusing text around this. My  
guess is that RELOAD would have no problems with NAT66 or NAT64 but we  
should carefully go and check this works.

Cullen <with my individual contributor hat on>

On Mar 23, 2009, at 18:47 , james woodyatt wrote:

> An interesting thing about this document: it doesn't discuss  
> P2PSIP.  I went looking to see how P2PSIP would be affected by  
> NAT66, and the answer seems to me that P2PSIP uses TURN for doing  
> NAT traversal (see the highly amusing <http://tools.ietf.org/html/draft-ietf-behave-turn-ipv6 
> I've a feeling that NAT66 complicates the bootstrap process for  
> P2PSIP overlays, but I'm not sure how.  I don't think I see how  
> P2PSIP bootstrap servers can be deployed behind NAT66 without  
> tightly coupled coordination with the NAT, and I wonder about Fred's  
> ideas about hairpin denial in that case...
>
>
> --

---

From: james woodyatt <[email-masked]>
Date: Tue, 24 Mar 2009 14:33:23 -0700

On Mar 24, 2009, at 14:10, Cullen Jennings wrote:
> Interesting question and we should go and check the details on this.  
> I have no idea where you are getting the idea that the  "bootstrap  

I probably failed to grasp the context of draft-matthews-p2psip- 
bootstrap-mechanisms, section 2.2 Bootstrap Server Mechanism: "A  
P2PSIP Bootstrap Server is a SIP registrar and proxy, typically  
located in the public Internet, that acts as an intermediary to  
introduce the joining peer to a bootstrap peer..."

I also probably failed to remember that the thing I was thinking about  
is called the enrollment server, not the bootstrap service.  The  
enrollment service is probably implemented with an HTTPS server in  
most cases, and the XML document that it returns for requests to  
enroll includes a list of bootstrap peers by their IP address.  It's  
*those* IP address that I'm concerned with, as they are address  
referrals.

How does the enrollment client and the enrollment server negotiate for  
address realm differences?  I suspect I know how this is done for  
IPv4, i.e. it isn't; the enrollment server and the bootstrap peers are  
all assumed to have addresses in the same address realm, usually the  
public realm, for the purpose of the overlay.  Therefore, if the  
enrollment server is reachable from more than one realm through  
translators, then the bootstrap peers in the enrollment response must  
all have the same addresses in every realm or the overlay doesn't  
work.  This isn't an IPv6-specific thing.

The complication NAT66 presents for P2PSIP is that we don't even have  
the moral equivalent of RFC 1918 space for IPv6.  We don't have any  
helpful hint, looking at any particular global-scope IP address,  
whether it's in the same address realm as us or not.  At least, with  
IPv4, when you see RFC 1918 addresses, then you know they're not the  
public address realm, and that can sometimes help, i.e. an enrollment  
server that knows it's running in the public address realm can make  
sure it never designates a bootstrap peer with an RFC 1918 address.   
The IPv6 case isn't as simple.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 24 Mar 2009 14:40:48 -0700

Ah, ok - I was looking at the WG documents not that one.

On Mar 24, 2009, at 14:33 , james woodyatt wrote:

>> Interesting question and we should go and check the details on  
>> this. I have no idea where you are getting the idea that the   
>> "bootstrap service is defined as a SIP registrar and proxy" - the  
>> RELOAD bootstrap does not  have anything to do with SIP.
>
> I also probably failed to remember that the thing I was thinking  
> about is called the enrollment server, not the bootstrap service.   
> The enrollment service is probably implemented with an HTTPS server  
> in most cases, and the XML document that it returns for requests to  
> How does the enrollment client and the enrollment server negotiate  
> for address realm differences?  I suspect I know how this is done  
> for IPv4, i.e. it isn't; the enrollment server and the bootstrap  
> peers are all assumed to have addresses in the same address realm,  
> usually the public realm, for the purpose of the overlay.   
> Therefore, if the enrollment server is reachable from more than one  
> realm through translators, then the bootstrap peers in the  
> enrollment response must all have the same addresses in every realm  
> or the overlay doesn't work.  This isn't an IPv6-specific thing.
>
> The complication NAT66 presents for P2PSIP is that we don't even  
> have the moral equivalent of RFC 1918 space for IPv6.  We don't have  
> any helpful hint, looking at any particular global-scope IP address,  
> public address realm, and that can sometimes help, i.e. an  
> enrollment server that knows it's running in the public address  
> realm can make sure it never designates a bootstrap peer with an RFC  
> 1918 address.  The IPv6 case isn't as simple.
>
>
> --

---

From: Ted Hardie <[email-masked]>
Date: Wed, 25 Mar 2009 11:05:18 -0700

>return packets will go back through a NAT66 box to be translated back 

I am sure I am misunderstanding this here.  It sounds like you are
saying that instead of this:

Application desires to contact service provided on some node on the 'net.

It causes its node's DNS to collect one or more addresses from the relevant
dns server.

It constructs a flow such that its source address is selected according to the
existing mechanism (selecting a global scope address for anything beyond
the link scope, since ULAs are global scope here).

The packets in these flows go through normal routing to some administrative
boundary at which boundary they are altered by this new box. 

That alteration changes their source address to some PA-relevant source
address for the upstream network.

It goes out into the wild world, where response packets are constructed,
using this new source address as destination addresses.  Those reach the
same box as before (or a box that has state on the transformation) which
alters them to carry the original source address.

You want to do or allow this:

Application desires to contact service provided on some node on the 'net.

It causes its node's DNS to collect one or more addresses from the relevant
dns server.  That information is altered such that one or more of the addresses
is related to a specific local scope (e.g. matches the local ULA).

[DNSSEC breaks here]

The host constructs a flow such that its source address is selected according
to the existing mechanism (selecting the local scope in the DNS packets it
just got back).

It sends out a packet which is then updated as above and is returned as
above.

I *have* to be getting this wrong.  What is the right step here?

Ted