Subject: Re: [BEHAVE] Pref64 nature and referral support.

From: <[email-masked]>
Date: Thu, 5 Feb 2009 10:04:51 +0100

Inline,

>-----Original Message-----
>From: ext Rémi Després [mailto:[email-masked]]
>Sent: 24 January, 2009 12:07
>To: Brian E Carpenter
>Cc: Dan Wing; 'Behave WG'; Savolainen Teemu (Nokia-D-MSW/Tampere)
>Subject: Re: [BEHAVE] Pref64 nature and referral support.
>
>>> As chair, I would certainly like to see documents that detail such
>>> proposals.  A discussion of the trade-offs and benefits would be
>>> valuable.
>To my knowledge, and for example, Teemu Savolainen ran a test
>in August 2008. It showed that a Google map use involved 4
>server addresses in parallel. With port dependent mapping on
>port 80, the number of needed client ports would have been
>divided by 4 .

Correct.

To be more exact, one test showed burst of 8 SYNs:
- TCP SYN to 74.125.77.136:80 (local port 1380) => requires new local port reservation 1
- TCP SYN to 74.125.77.136:80 (local port 1381) => requires new local port reservation 2
- TCP SYN to 74.125.77.93:80 (local port 1382) => could have shared existing local port '1'
- TCP SYN to 74.125.77.93:80 (local port 1383) => could have shared existing local port '2'
- TCP SYN to 74.125.77.91:80 (local port 1384) => could have shared existing local port '1'
- TCP SYN to 74.125.77.91:80 (local port 1385) => could have shared existing local port '2'
- TCP SYN to 74.125.77.190:80 (local port 1386) => could have shared existing local port '1'
- TCP SYN to 74.125.77.190:80 (local port 1387) => could have shared existing local port '2'

I.e. 8 different TCP sessions could have been multiplexed into 2 local ports.

And another test showed burst of 16 SYNs:
- TCP SYN to 74.125.77.93:80 (local port 1906) => requires new local port reservation 1
- TCP SYN to 74.125.77.136:80 (local port 1907) => could have shared existing local port '1'
- TCP SYN to 74.125.77.91:80 (local port 1908) => could have shared existing local port '1'
- TCP SYN to 74.125.77.91:80 (local port 1909) => requires new local port reservation 2
- TCP SYN to 74.125.77.190:80 (local port 1910) => could have shared existing local port '1'
- TCP SYN to 74.125.77.190:80 (local port 1911) => could have shared existing local port '2'
- TCP SYN to 74.125.77.190:80 (local port 1912) => requires new local port reservation 3
- TCP SYN to 74.125.77.136:80 (local port 1913) => could have shared existing local port '2'
- TCP SYN to 74.125.77.136:80 (local port 1914) => could have shared existing local port '3'
- TCP SYN to 74.125.77.93:80 (local port 1915) => could have shared existing local port '2'
- TCP SYN to 74.125.77.91:80 (local port 1916) => could have shared existing local port '3'
- TCP SYN to 74.125.77.93:80 (local port 1917) => could have shared existing local port '3'
- TCP SYN to 74.125.77.93:80 (local port 1918) => requires new local port reservation 4
- TCP SYN to 74.125.77.136:80 (local port 1919) => could have shared existing local port '4'
- TCP SYN to 74.125.77.91:80 (local port 1920) => could have shared existing local port '4'
- TCP SYN to 74.125.77.190:80 (local port 1921) > could have shared existing local port '4'

For me it looked like there could have been possibility for 75% local port savings in these two scenarios.

Of course if the destination server is having just one IP address, these kinds of savings would not be possible for such applications utilizing multiple parallel transport sessions. Maybe these kinds of applications should be hosted by servers with multiple IP addresses (even if all configured for same interface)?

What comes to hosts possibly having port restricted IP address allocated to themselves, it would seem they should utilize address dependent mapping (when applications are utilizing implicit source port bindings) to save ports in these kinds of use-cases (also in the case where the host implements internal NAT (for serving non-port-restricted IPv4 address compatible applications)).

Best regards,

        Teemu

---

From: Philip Matthews <[email-masked]>
Date: Mon, 9 Feb 2009 20:39:59 -0500

[Catching up on a backlog of NAT64-related e-mails...]

Personally, I don't think we are going to make referrals work, for a  
variety of reasons.

One of the main things we have learned from the whole STUN/TURN/ICE  
development process is that, in the presence of NATs, a node does not  
have just one IP address, but multiple IP addresses: one of these  
address may work from one location and a different address may work  
from a different location. Furthermore, it is almost impossible to  
provide an easy rule to predict which address will work from which  
location (We tried creating easy rules with the first version of STUN  
(as described in RFC 3489), but it proved unreliable and thus ICE was  
invented). This is the reason why an ICE endpoint gathers all the  
addresses ("candidates") it can find and sends them all to the other  
endpoint, and then all pair-wise combinations are tried.

Furthermore, as Dan has pointed out, almost all NATs today have  
filtering rules that prevent packets from the "outside" from passing  
through the NAT unless a packet from the "inside" has previously been  
sent out. Dan has suggested that NAT64s could implement "endpoint- 
independent filtering", but I think this is very unlikely since by far  
the most common rule today is some form of "endpoint-dependent  
filtering"

For these reasons, the only reliable way to do a referral is to pass  
some sort of symbolic name for the referred-to node, and use some form  
of rendezvous server to establish a direct connection. In the terms  
used by Marcelo below, Node A passes to Node C a symbolic name for  
Node B, and then Node C contacts a rendezvous server and uses ICE to  
establish a direct connection with node B.

Which rendezvous server node C uses depends on the context. It may be  
that Node A can act as the rendezvous server -- this is the technique  
being used in the P2PSIP working group to add a peer to a peer-to-peer  
network. It may also be that there is some generic rendezvous server  
--- the HIP group has done some investigations along this line.

Thus I think we should drop the referral criterion when considering  
the nature of the Pref64.

- Philip

On Tue, 20-Jan-09, at 06:33 , marcelo bagnulo braun wrote:

> The topic of this mail is the impact of the prefix type selected for  
> representing the IPv4 addresses in the IPv6 Internet (from now  
> called Pref64::/N) in the referral operations.
>
> A referral operation is when a host A passes the IP address of a  
> Host B to a third Host C as application data. The host Host C will  
> then initiate a communication towards the Host B using the IP  
> address received. I understand this is not a rare operation in VoIP  
> type of applications, but Dan will correct me if this is just a IP  
> area legend (that, by the way, is used, sometimes, as an argument to  
> build overly complex solutions :-)
>
> There are several referrals scenarios as described in this table:
>
>      | Host A | Host B | Host C |
> ---------------------------------------
> Scenario 1 |   v6   |   v6   |   v4   |
> ---------------------------------------
> Scenario 2 |   v6   |   v4   |   v6   |
> ---------------------------------------
> Scenario 3 |   v4   |   v6   |   v6   |
> ---------------------------------------
> Scenario 4 |   v6   |   v4   |   v4   |
> ---------------------------------------
> Scenario 5 |   v4   |   v6   |   v4   |
> ---------------------------------------
> Scenario 6 |   v4   |   v4   |   v6   |
> ---------------------------------------
>
> Now, all the scenarios where Host A and Host C are in different IP  
> version, they require a specific ALG, since the IP address  
> information contained as application data must be translated, in  
> order to be meaningful a the receiver (these are scenarios 1, 3, 4  
> and 6).
>
> OTOH, scenarios 2 and 5 could work without ALG.
>
> In addition, scenarios 1 and 5 where Host C is IPv4 and  Host B is  
> IPv6 will need some form of static NAT configuration (either the  
> stateless mode of IVI or the manual configuration of bindings) to  
> work cause they imply an IPv4 node initiating a communication  
> towards and IPv6 node.
>
>
> So, let's consider the scenario 2, which should work in the dynamic  
> binding case without ALGs first:
>
> **Scenario 2 is as follows
>
>
> +-----------------------------------------+
> | IPv4 Internet                           |
> |                +--------+               |
> |                | Host B |               |
> |                | IPB    |               |
> |                +--------+               |
> +-----------------------------------------+
> |                                  |
> |                                  |
> +--|----------------------------------|---+
> |+-|--------+    +-------+   +--------|--+|
> || Pref64_1 |    |       |   | Pref64_2  ||
> ||          |    |       |   |           ||
> || +------+ |    |       |   | +-------+ ||
> || |Host A| |----|       |---| |Host C | ||
> || +------+ |    |       |   | +-------+ ||
> || Site1    |    +-------+   | Site2     ||
> |+----------+                +-----------+|
> |                                         |
> | IPv6 Internet                           |
> +-----------------------------------------+
>
> So, in this case, Host A will be sending Host B's address to Host C  
> as application data.
> Now, in the eyes of Host A, Host B's address is Pref64_1:IPB:suffix  
> (the suffix is optional, depending whether Pref64_1 is 96 bit long  
> or shorter.
>
> Host C will receive then Pref64_1:IPB:suffix and will try to  
> initiate a communication toward host B using that address.
>
> We now have two options depending if the prefix Pref64_1 is a single  
> well known prefix or is allocated from the site's address block.
>
> - Case where the Pref64_1 is allocated from the site's address block  
> (FWIW this what all drafts do as currently described)
> Host C sends a packet towards Pref64_1:IPB:suffix.
> The packet is routed towards Site 1 since Pref64_1 is part of site's  
> 1 address block.
> Now Site 1 has 3 options, as discussed yesterday with Xing. Either  
> forwards the packet to the IPv4 internet or drops it (it can drop it  
> at the ingress or in the translator box). Now, as i understand it,  
> it doens't make economical sense for site 1 to forward the packet  
> towards the v4 internet, cause if it did so, it would be providing  
> free v6 to v4 transit. So, as i understand it, it makes sense for  
> site 1 to drop the packet (which is what i understand CERNET does  
> (in their case it is a bit more complicated, cause they also have a  
> the IVI addresses that they handle differently, but i think this  
> applies in their case as well, modulo those addresses))
>
> Now, if site1 drops packets addressed to Pref64_1 coming from the  
> outside, referrals break.
>
> - Case where the Pref64_1 is a single well know prefix.
> In this case Pref64_1=Pref64_2=Pref64
> So, HostA sends Pref64:IPB_suffix to Host C
> Host C now sends a packet to Pref64:IPB:suffix.
> In this case, the packet will flow through whatever route Site2 has  
> to connect to the IPv4 Internet. In our scheme, site2 has its own  
> translator, that then would announce a route towards Pref64, so the  
> packet will flow through the direct route Site2 has to the IPv4  
> Internet.
>
> So, from this analysis, it seems that in this case, referrals would  
> work if a single well know prefix is used.
>
>
> So, let's think a bit about the scenarios that require al ALG next.
>
>
> ** Scenarios 1, 3, 4 and 6
>
> A general observation about these scenarios is that in the case a  
> single well know prefix is used, it would be possible for the ALG to  
> identify  the IPv6 addresses  containing an embedded IPv4 address  
> and translate it, cause they could identify the well know prefix and  
> know that are not general use IPv6 addresses. If the Pref64 is taken  
> from the site's address block, it may be possible for the ALG to  
> translate the address in the referral, as long as the translator is  
> configured to know that this specific prefix is unsed to map IPv4  
> addresses. This basically implies that the translator must be in  
> Site1 in the figure above, i.e. the site of the host sending the  
> referral information.
>
> So, we can say that a single well known prefix is more likely to  
> work with referral in the case that ALG is needed than  the case of  
> the  prefix taken from the site's address block.
>
> *** So, we have scenario 5 to go
>
> Host A is v4, host B is v6 and host C is v4
>
> In this case, we need a representation of Host B in the v4 world. In  
> this case, the Pref64 seems hardly relevant.
>
> So, i think it is reasonable to say that a single well know prefix  
> would result in better referral support.
> I wonder if this cannot be generalized for other applications. I  
> mean after all the better support is simply due to the fact that  
> using a single well know prefix results in a unique representation  
> of the v4 addresses in v6 land, and allows to identify that  
> irrespectivly where the translation is performed, the result is the  
> same in terms of the address.
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

---

From: Xing Li <[email-masked]>
Date: Tue, 10 Feb 2009 15:39:35 +0800

Hi, All,

We have uploaded a new version of  "IP/ICMP Translation Algorithm", 
please comment. Thanks.

http://www.ietf.org/internet-drafts/draft-baker-behave-v4v6-translation-01.txt

xing

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 10 Feb 2009 10:13:33 +0100

Philip Matthews escribió:
> from a different location.

I understand that what you are saying i correct for IPv4 NATs, but it 
dones' have to be for NAT64, in the following sense. In IPv4 NATs, it is 
clear that the binding between the public transport address and the 
private transport address has a very limited lifetime. SO, the public 
transport address is clearly not a stable name, that  can can hardly be 
used for referrals.
Now, in NAT64 this will certainly be the case when you use an IPv4 
address for the referral, since the binding between the general IPv6 
address and the public IPv4 address will have the same limited lifetime.
However, i don't applies to the IPv6 addresses that represent IPv4 
addresses, since the binding is automatically created, hence it does not 
longer has this limited lifetime nature.

I mean, if an app uses an IPv4 address that has been assigned by a NAT a 
couple of hours later, it is likely that the binding will not exsit, and 
hence the referral won't work. If an app uses an IPv6 address 
representing an IPv4 address a couple of hours later, if the binding 
does not exsits, it can be created again, and the referal will work.

So, it is my take that the analogy with the IPv4 case does not applies here

(With this automatic binding creation we get rid of the time dependency 
and the argument for using the well known prefix is that we get rid of 
the topological dependency)
> Furthermore, it is almost impossible to provide an easy rule to 
> predict which address will work from which location (We tried creating 
> easy rules with the first version of STUN (as described in RFC 3489), 
> but it proved unreliable and thus ICE was invented). This is the 
> reason why an ICE endpoint gathers all the addresses ("candidates") it 
> can find and sends them all to the other endpoint, and then all 
> pair-wise combinations are tried.
>
> sent out. Dan has suggested that NAT64s could implement 
> "endpoint-independent filtering", but I think this is very unlikely 
> since by far the most common rule today is some form of 
> "endpoint-dependent filtering"
>
First, i think that the main reasons why referals don't work is cause 
the binding have expired rather than cause they are filtered.
Second, one thing is to administratively fliter referals and anohter 
compeltelly different is to design a solution that simply is much less 
likely to make them work.
In the first case we can disable the filter if we want in the second 
case, we need to change the technology

> establish a direct connection with node B.
exactly, the name could be the IPv6 address that represents the IPv4 
address usingt he well know prefix, since it will be a universal 
representation of the IPv4 address in IPv6 land

Regards, marcelo

>> representing the IPv4 addresses in the IPv6 Internet (from now called 
>> Pref64::/N) in the referral operations.
>>
>> A referral operation is when a host A passes the IP address of a Host 
>> B to a third Host C as application data. The host Host C will then 
>> initiate a communication towards the Host B using the IP address 
>> received. I understand this is not a rare operation in VoIP type of 
>> applications, but Dan will correct me if this is just a IP area 
>> legend (that, by the way, is used, sometimes, as an argument to build 
>> overly complex solutions :-)
>>
>> work cause they imply an IPv4 node initiating a communication towards 
>> and IPv6 node.
>>
>>
>> (the suffix is optional, depending whether Pref64_1 is 96 bit long or 
>> shorter.
>>
>> Host C will receive then Pref64_1:IPB:suffix and will try to initiate 
>> a communication toward host B using that address.
>>
>> at the ingress or in the translator box). Now, as i understand it, it 
>> doens't make economical sense for site 1 to forward the packet 
>> site 1 to drop the packet (which is what i understand CERNET does (in 
>> their case it is a bit more complicated, cause they also have a the 
>> IVI addresses that they handle differently, but i think this applies 
>> in their case as well, modulo those addresses))
>>
>> identify  the IPv6 addresses  containing an embedded IPv4 address and 
>> translate it, cause they could identify the well know prefix and know 
>> that are not general use IPv6 addresses. If the Pref64 is taken from 
>> the site's address block, it may be possible for the ALG to translate 
>> the address in the referral, as long as the translator is configured 
>> to know that this specific prefix is unsed to map IPv4 addresses. 
>> This basically implies that the translator must be in Site1 in the 
>> figure above, i.e. the site of the host sending the referral 
>> information.
>>
>> So, we can say that a single well known prefix is more likely to work 
>> with referral in the case that ALG is needed than  the case of the  
>> prefix taken from the site's address block.
>>
>> I wonder if this cannot be generalized for other applications. I mean 
>> after all the better support is simply due to the fact that using a 
>> single well know prefix results in a unique representation of the v4 
>> addresses in v6 land, and allows to identify that irrespectivly where 
>> the translation is performed, the result is the same in terms of the 
>> address.
>>

---

From: Philip Matthews <[email-masked]>
Date: Thu, 12 Feb 2009 17:44:26 -0500

Hi Marcelo:

There are three things that can break referrals in the presence of NATs:
* The binding lifetime
* Filtering
* Topology or whether the binding ever existing or could exist

Regarding filtering, most NATs today do either address-dependent or  
address-and-port dependent filtering, and this is seen as a selling  
point. People want to put their hosts behind some sort of filtering  
NAT or firewall to block attacks, and I don't think this is going to  
change. So even in a pure IPv6 network, referrals will not necessarily  
work.

Regarding topology, if multiple NATs are involved, then referrals can  
break. Consider, for example, the following case:

              Host C
          (IPv6 network)

              NAT64

         IPv4 Internet

              NAT64

          (IPv6 network)
       Host A       Host B

Here all three hosts are located in IPv6 networks, but if Host A  
passes to Host C the address of Host B, C will be unable to contact B.  
(You can complain that there should be a pure IPv6 path between the  
two IPv6 networks, but if NAT64 is successful, I am sure this case  
will happen often).

More fundamentally, referrals to hosts don't work today in the IPv4  
Internet because of NAT44s and firewalls, and application designers  
(especially those designing VoIP and p2p apps) are developing  
mechanisms (like STUN/TURN/ICE) to adapt.

Any successful application in the mixed IPv4/IPv6 world will need to  
handle the existing IPv4 Internet situation. Given that, I think we  
simply need to make sure that these mechanisms still work.

- Philip

On Tue, 10-Feb-09, at 04:13 , marcelo bagnulo braun wrote:

>> Personally, I don't think we are going to make referrals work, for  
>> a variety of reasons.
>>
>> development process is that, in the presence of NATs, a node does  
>> not have just one IP address, but multiple IP addresses: one of  
>> these address may work from one location and a different address  
>> may work from a different location.
>
> I understand that what you are saying i correct for IPv4 NATs, but  
> it dones' have to be for NAT64, in the following sense. In IPv4  
> NATs, it is clear that the binding between the public transport  
> address and the private transport address has a very limited  
> lifetime. SO, the public transport address is clearly not a stable  
> name, that  can can hardly be used for referrals.
> addresses, since the binding is automatically created, hence it does  
> not longer has this limited lifetime nature.
>
> I mean, if an app uses an IPv4 address that has been assigned by a  
> NAT a couple of hours later, it is likely that the binding will not  
> exsit, and hence the referral won't work. If an app uses an IPv6  
> address representing an IPv4 address a couple of hours later, if the  
> binding does not exsits, it can be created again, and the referal  
> will work.
>
> (With this automatic binding creation we get rid of the time  
> dependency and the argument for using the well known prefix is that  
> we get rid of the topological dependency)
>> predict which address will work from which location (We tried  
>> creating easy rules with the first version of STUN (as described in  
>> RFC 3489), but it proved unreliable and thus ICE was invented).  
>> This is the reason why an ICE endpoint gathers all the addresses  
>> ("candidates") it can find and sends them all to the other  
>> filtering rules that prevent packets from the "outside" from  
>> passing through the NAT unless a packet from the "inside" has  
>> previously been sent out. Dan has suggested that NAT64s could  
>> implement "endpoint-independent filtering", but I think this is  
>> very unlikely since by far the most common rule today is some form  
>> of "endpoint-dependent filtering"
>>
> First, i think that the main reasons why referals don't work is  
> cause the binding have expired rather than cause they are filtered.
> compeltelly different is to design a solution that simply is much  
> less likely to make them work.
>> For these reasons, the only reliable way to do a referral is to  
>> pass some sort of symbolic name for the referred-to node, and use  
>> some form of rendezvous server to establish a direct connection. In  
>> the terms used by Marcelo below, Node A passes to Node C a symbolic  
>> name for Node B, and then Node C contacts a rendezvous server and  
>> uses ICE to establish a direct connection with node B.
>>
>> Which rendezvous server node C uses depends on the context. It may  
>> be that Node A can act as the rendezvous server -- this is the  
>> technique being used in the P2PSIP working group to add a peer to a  
>> peer-to-peer network. It may also be that there is some generic  
>> rendezvous server --- the HIP group has done some investigations  
>> along this line.
>>
>>> The topic of this mail is the impact of the prefix type selected  
>>> for representing the IPv4 addresses in the IPv6 Internet (from now  
>>> address received. I understand this is not a rare operation in  
>>> VoIP type of applications, but Dan will correct me if this is just  
>>> a IP area legend (that, by the way, is used, sometimes, as an  
>>> argument to build overly complex solutions :-)
>>>
>>> So, let's consider the scenario 2, which should work in the  
>>> dynamic binding case without ALGs first:
>>>
>>> So, in this case, Host A will be sending Host B's address to Host  
>>> C as application data.
>>> Now, in the eyes of Host A, Host B's address is  
>>> Pref64_1:IPB:suffix (the suffix is optional, depending whether  
>>> Pref64_1 is 96 bit long or shorter.
>>>
>>> We now have two options depending if the prefix Pref64_1 is a  
>>> single well known prefix or is allocated from the site's address  
>>> block.
>>>
>>> - Case where the Pref64_1 is allocated from the site's address  
>>> block (FWIW this what all drafts do as currently described)
>>> The packet is routed towards Site 1 since Pref64_1 is part of  
>>> site's 1 address block.
>>> forwards the packet to the IPv4 internet or drops it (it can drop  
>>> it at the ingress or in the translator box). Now, as i understand  
>>> it, it doens't make economical sense for site 1 to forward the  
>>> packet towards the v4 internet, cause if it did so, it would be  
>>> providing free v6 to v4 transit. So, as i understand it, it makes  
>>> sense for site 1 to drop the packet (which is what i understand  
>>> CERNET does (in their case it is a bit more complicated, cause  
>>> they also have a the IVI addresses that they handle differently,  
>>> but i think this applies in their case as well, modulo those  
>>> addresses))
>>>
>>> In this case, the packet will flow through whatever route Site2  
>>> has to connect to the IPv4 Internet. In our scheme, site2 has its  
>>> own translator, that then would announce a route towards Pref64,  
>>> so the packet will flow through the direct route Site2 has to the  
>>> IPv4 Internet.
>>>
>>> So, from this analysis, it seems that in this case, referrals  
>>> would work if a single well know prefix is used.
>>>
>>>
>>> single well know prefix is used, it would be possible for the ALG  
>>> to identify  the IPv6 addresses  containing an embedded IPv4  
>>> address and translate it, cause they could identify the well know  
>>> prefix and know that are not general use IPv6 addresses. If the  
>>> Pref64 is taken from the site's address block, it may be possible  
>>> for the ALG to translate the address in the referral, as long as  
>>> the translator is configured to know that this specific prefix is  
>>> unsed to map IPv4 addresses. This basically implies that the  
>>> translator must be in Site1 in the figure above, i.e. the site of  
>>> the host sending the referral information.
>>>
>>> work with referral in the case that ALG is needed than  the case  
>>> of the  prefix taken from the site's address block.
>>>
>>> In this case, we need a representation of Host B in the v4 world.  
>>> In this case, the Pref64 seems hardly relevant.
>>>
>>> irrespectivly where the translation is performed, the result is  
>>> the same in terms of the address.
>>>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 17 Feb 2009 11:49:51 +0100

Hi Phillip,

sorry for the delay, replies below...

> change. So even in a pure IPv6 network, referrals will not necessarily 
right
This would also apply to firewalls.
Now, i can understand that people can have security policy that prevents 
this from working and i am fine with that.
the thing about security policy is that other sits can have a different 
policy and referrals would work for them. It is actually an operation 
choice of the site and that is good.
IMHO it is a completelly different thing to make a technology that by 
design breaks referrals, i simply don't think this is a good idea

> two IPv6 networks, but if NAT64 is successful, I am sure this case 
it depends, right?
I mean, if the binding is still alive, it would be able to contact
If the binding has expired, it won't
But if the binding has expired, then Host C wouldn't be able to receive 
any incoming communication and not because this is not supported in this 
scenarion, you would argue that supporting incoming communication is not 
needed in general, right?

Bottom line is that we have challenging scenarios, and we should try to 
design a solution that works in the highest number of scenarios that we can

> Internet because of NAT44s and firewalls,

i think this is a bit too assertive for my taste.

> and application designers (especially those designing VoIP and p2p 
> apps) are developing mechanisms (like STUN/TURN/ICE) to adapt.
>

but this is not a valid reason to design a solution that by design does 
not support them by design

> handle the existing IPv4 Internet situation.
i agree
this doesn't imply that we cannot try to design a protocol that can work 
if the scenario is appropriate

regards, marcelo

> Given that, I think we simply need to make sure that these mechanisms 
> still work.
>

>>> these address may work from one location and a different address may 
>>> work from a different location.
>>
>> dones' have to be for NAT64, in the following sense. In IPv4 NATs, it 
>> is clear that the binding between the public transport address and 
>> the private transport address has a very limited lifetime. SO, the 
>> public transport address is clearly not a stable name, that  can can 
>> hardly be used for referrals.
>>> RFC 3489), but it proved unreliable and thus ICE was invented). This 
>>> is the reason why an ICE endpoint gathers all the addresses 
>>> ("candidates") it can find and sends them all to the other endpoint, 
>>> and then all pair-wise combinations are tried.
>>>
>>> through the NAT unless a packet from the "inside" has previously 
>>> been sent out. Dan has suggested that NAT64s could implement 
>>> some sort of symbolic name for the referred-to node, and use some 
>>> form of rendezvous server to establish a direct connection. In the 
>>> terms used by Marcelo below, Node A passes to Node C a symbolic name 
>>> for Node B, and then Node C contacts a rendezvous server and uses 
>>> ICE to establish a direct connection with node B.
>>>
>>>> area legend (that, by the way, is used, sometimes, as an argument 
>>>> to build overly complex solutions :-)
>>>>
>>>> CERNET does (in their case it is a bit more complicated, cause they 
>>>> also have a the IVI addresses that they handle differently, but i 
>>>> think this applies in their case as well, modulo those addresses))
>>>>

---

From: Jari Arkko <[email-masked]>
Date: Fri, 20 Feb 2009 20:29:56 +0200

Marcelo,

> Now, i can understand that people can have security policy that 
> prevents this from working and i am fine with that.
> the thing about security policy is that other sits can have a 
> different policy and referrals would work for them. It is actually an 
> operation choice of the site and that is good.

That's right. We do need to attempt to keep as much of the end-to-end 
functionality intact as is possible. Of course people can add rules to 
allow and disallow various kinds of traffic flows, but it is in 
everyone's best interests to keep the translation component and firewall 
components as separate as possible.

Jari

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 20 Feb 2009 11:12:38 -0800

Jari Arkko wrote:
> functionality intact as is possible. Of course people can add 
> rules to allow and disallow various kinds of traffic flows, but 
> it is in everyone's best interests to keep the translation 
> component and firewall components as separate as possible.

Referrals across a translator seem difficult at best though:
at least two applications that commonly do referrals (SIP and
BitTorrent) only use IP addresses, but referring a synthetic
IPv6 address to an IPv4 host will never work.  Referring a 
synthetic IPv6 address to an IPv6 host belonging to another
ISP will not work (an ISP is unlikely to operate NAT64 devices
for the benefit of any IPv6 host on the Internet that wants to
use it).

I have more details written up on this topic and will write
an I-D to present in San Francisco.

-d

---

From: Jari Arkko <[email-masked]>
Date: Fri, 20 Feb 2009 21:33:11 +0200

Dan,

> for the benefit of any IPv6 host on the Internet that wants to

There are a few different cases depending on what version is used on the 
node that gives out the reference, where it is received, and where it 
points to. It seems that there are a few cases that would potentially 
work, though I do agree that there are many work that would not.

For instance, lets say you and I are both in IPv6-only networks at 
different sites and I pass you Marcelo's address. Marcelo is in the IPv4 
space, so I give you prefix64::marcelo. If you and I happen to use the 
same prefix64 to represent IPv4 space, then it seems possible for you to 
contact Marcelo.

> an I-D to present in San Francisco.

Good -- looking forward to that. I guess Marcelo's draft on prefixes 
will also be relevant here.

Jari

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 20 Feb 2009 12:06:58 -0800

> same prefix64 to represent IPv4 space, then it seems possible 
> for you to contact Marcelo.

Yes, that case works because both of our ISPs have deployed
NAT64 devices and both use the same well-known prefix.

But if I am IPv4-only, that IPv6 address won't be useful to me.

If I am dual-stack, that IPv6 address won't work -- at least,
not until my ISP provides me with a NAT64 device using that
same well-known prefix.

Considering today's Internet users are somewhere around ~95% 
IPv4-only and 5% dual-stack this means that initial deployments 
of NAT64 will break referrals across the translator.  It is only 
after NAT64 has been deployed in both my network and in your 
network, and both using a well-known prefix, that we could 
have IPv6 referrals work between IPv4 and IPv6.

Question:  what applications do referrals?  BitTorrent and 
SIP come to my mind, and both do referrals using IP addresses
(not DNS names).  (To be precise, SIP's use of SDP does referrals
using IP addresses; SIP's message routing usually uses DNS names).
Are there others that we could characterize?

> will also be relevant here.

Yes.

-d

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 22 Feb 2009 21:46:10 +0100

Dan Wing escribió:
> IPv6 address to an IPv4 host will never work. 
mmm, but if you have a SIP ALG it could work, right? and using a well 
know prefix would make the life of the ALG much simpler, since it would 
be able to recognize an IPv6 represetnation of an IPv4 address and 
translate it into the embedded IPv4 address

>  Referring a 
but, if you use the well know prefix this owuld work, cause the traffic 
would flow through the NAT64 located in each ISP, right?

regards, marcelo

---

From: Christian Huitema <[email-masked]>
Date: Sun, 22 Feb 2009 16:51:43 -0800

> translate it into the embedded IPv4 address

Nope. It might work in some limited scenarios, but it will not work in the general case. First, there is no guarantee that the translator will see the SIP traffic. The traffic is send by the clients to the server, while the media, for which the translation is negotiated, is sent on a direct path to the clients. How would a translator apply an ALG to traffic that it does not see? Then, even if the SIP traffic did flow through the translator, in many case the traffic is sent over an encrypted TLS channel. The translator will not even know it is SIP. And then, even if the traffic was sent in clear text through the translator, the SDP payload can well be signed or otherwise protected, so no chance for an ALG here either.

There is a reason STUN, TURN and ICE are being developed.

-- Christian Huitema

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 23 Feb 2009 09:29:52 +0100

Christian Huitema escribió:
> Nope. It might work in some limited scenarios, but it will not work in the general case. First, there is no guarantee that the translator will see the SIP traffic. The traffic is send by the clients to the server, while the media, for which the translation is negotiated, is sent on a direct path to the clients. How would a translator apply an ALG to traffic that it does not see? 

but in this case there should be another translator along the media 
path, right? (i mean, assuming you are trying to communicate a v4 node 
and a v6 node)

> Then, even if the SIP traffic did flow through the translator, in many case the traffic is sent over an encrypted TLS channel.

right, but this is a completelly different scenario imho

If you are using TLS or even worse, IPSec, then translators are very 
unlikely to work in general cases.

I mean, bottom line is that i understand that the argument here is how 
to make translators so that referrals, in the general case, SIP being an 
example, are more likely to work.

In particular, when we need to select a prefix to represent IPv4 
addresses in the IPv6 internet, whether using a single well known prefix 
or that each sites uses a sub prefix of their own prefixes makes life 
easier for referrals.

This doesn't implies that referrals will work in every case, i know, but 
that the are more likely to work

Regards, marcelo

>  The translator will not even know it is SIP. And then, even if the traffic was sent in clear text through the translator, the SDP payload can well be signed or otherwise protected, so no chance for an ALG here either.
>

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 23 Feb 2009 12:23:59 -0800

> From: marcelo bagnulo braun [mailto:[email-masked]] 
> Sent: Sunday, February 22, 2009 12:46 PM
> To: Dan Wing
> Cc: 'Jari Arkko'; 'Behave WG'; 'Philip Matthews'

An ALG has to interact with the NAT and create state for the media
traffic in the NAT.  For a SIP ALG to work, the SIP traffic would have 
to traverse the same NAT as the media traffic and the SIP traffic
would have to be un-encrypted and not integrity protected.  With
those restrictions I do not think SIP ALGs are the answer.

> would flow through the NAT64 located in each ISP, right?

If that ISP operates a NAT64, yes.  So, referrals in that case
work once an ISP installs a NAT64 (or the subscriber has some
way to use someone else's NAT64, perhaps via a tunnel and a 
per-month fee, for example).  But my point is that existing IPv6
hosts and existing dual-stack hosts, in another ISP, cannot 
utilize a synthetic address.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 23 Feb 2009 12:31:22 -0800

...
> unlikely to work in general cases.

I keep hearing that, but I haven't seen details.  I am especially
interested in how TLS would fail because if we can't get HTTPS
to work across a translator, this will be deemed to have failed.

As for IPsec failing, I vaguely recall a summary of the problem 
posted to the list about the IP address inside of the IPsec 
tunnel, but I don't recall who posted that summary.  I don't
recall anything in an I-D.

> I mean, bottom line is that i understand that the argument 
> here is how to make translators so that referrals, in the general 
> case, SIP being an example, are more likely to work.
> 
> This doesn't implies that referrals will work in every case, 
> i know, but that the are more likely to work

We could require a SIP session border controller operate in the
translator.  That would make referrals work in every case.  But,
I don't think we want to go there, either..

-d

> Regards, marcelo
> 
> 
> >  The translator will not even know it is SIP. And then, 
> even if the traffic was sent in clear text through the 
> translator, the SDP payload can well be signed or otherwise 
> protected, so no chance for an ALG here either.
> >

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 23 Feb 2009 21:44:21 +0100

> utilize a synthetic address.

but that makes sense, right?

I mean this stuff doesn't work when your IPv6 ISP doesn't provide their 
customer with IPv4 Internet access (i.e it doesn't provide a NAT64) and 
the cleint itself doesn't pay to any other NAT64 provider.

So, if the client doesn't have access to the IPv4 Internet, not only 
referrals to the IPv4 internet break, any communication towards the IPv4 
internet break, cause he is not paying for that service

So, i think this is as much as he can for the money he pays, right?

In other words, this is not problem of the technology, but it is a 
porblem of the clietn that is not buying the service

Regards, marcelo

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 23 Feb 2009 13:06:43 -0800

> Sent: Monday, February 23, 2009 12:44 PM
> To: Dan Wing

The same referral of a synthetic IPv6 address also breaks to a 
dual-stack host, until/unless that dual-stack host's ISP operates
a NAT64.  And that will not make sense to someone operating
a dual-stack host -- they will expect referrals to work because
they are doing The Right Thing:  namely, operating a dual-stack 
host.

I'll write this all up into an I-D which will hopefully make
more sense.

-d

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 23 Feb 2009 23:18:47 +0100

> I'll write this all up into an I-D which will hopefully make
So, the case you are considering is:

Host A is IPv6-only
Host B is dual stack
Host C is IPv4-only

Host B is obtaining service from an IPv6-only ISP that has not access to 
the IPv4 internet
Host A do get IPv6 Internet access through a translator

So, host A passes the IPv6 representation of Host C IPv4 address to Host B.
Host B could access to Host C if it used the IPv4 address, but it cannot 
reach host C using the IPv6 representation cause its ISP is not 
providing NAT64 services, is that what you had in mind?

But, in this case, the Host B should be able to recognize, if a well 
known prefix is used, that the IPv6 address it has received is an IPv6 
representation of an IPv4 address and use IPv4 connectivity directly.

I mean, the bottom line here, is that when you pass IPv6 address that 
represent IPv4 addresses around, the well know prefix seems to behave 
much better, cause you can easily recognize that this is a represenation 
of an IPv4 address

Regards, marcelo

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 23 Feb 2009 15:16:02 -0800

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of marcelo bagnulo braun
> Sent: Monday, February 23, 2009 2:19 PM
> To: Dan Wing
> Cc: 'Behave WG'; 'Jari Arkko'; 'Philip Matthews'
> Host B is obtaining service from an IPv6-only ISP that has 
> not access to the IPv4 internet

No; Host B is dual-stack and fully-functioning (can access
both the v6 and v4 Internet).  However, Host B's ISP has
not installed a NAT64 device -- at least, not "yet".  Perhaps
Host B's ISP never will, because Host B's ISP believes that
dual-stack hosts are the right answer.  Perhaps Host B's ISP
will only ever install a NAT44 (in order to continue expanding
their business after IPv4 exhaustion).  Whatever the reason,
Host B's ISP does not operate a NAT64.  Host B is running
today's dual-stack OS (pick your favorite) and some dual-
stack capable stack.  If Host B (dual-stack) is referred to the 
synthetic IPv6 address for Host C (IPv4-only), Host B can't do 
anything useful -- it cannot communicate with Host C.  "One Would 
Expect" that Host B could communicate with Host C, though -- 
afterall, both of them are accessible over IPv4.

Resolutions include:
  1. tell Host B to run new software that is aware of the
     synthetic prefix, and strip that synthetic prefix.
     This allows Host B to connect to Host C using IPv4.
  2. tell Host A to run new software that is aware of the
     synethric prefix, and strip that synthetic prefix
     before referring Host C's IPv4 address.  This allows
     Host B to connect to Host C using IPv4.

There is another interesting scenario, though, using 
another host, Host D with is IPv4 only.

If the referral is to Host D (IPv4 only), we cannot hope 
to refer an IPv6 address to Host D.  We can only successful
refer an IPv4 address to an IPv4 only host.

To my analysis, if we want referrals to work across a NAT64,
we need to do (2), above -- namely, the host behind a NAT64
has to remove the synthetic IPv6 address prior to referring
the address.  Otherwise as soon as an IPv6-only host behind a
NAT64 host sends a referral to either an IPv4-only host or 
to a dual-stack host, the referral fails.

I will write this up into an I-D.

-d

---

From: <[email-masked]>
Date: Tue, 24 Feb 2009 09:33:39 +0900

Dan and Marcelo,

My suggestion is that we should not mix-up the two features of well-known prefix.

As you know well-known prefix has two aspects.
- Sythetic address identifier
- Routable Prefix
	(Common prefix to lead the packets to the translators on somewhere)

The former aspect is useful, of course.
The latter aspect is a bit dangerous that would cause some problems.
	It  means some people outside my routing realm can 
	control the traffic to lead to a translator.
	The behavior may or may not fit my routing policy.

So, the routing information and identification should be discussed separately.

And I have another concern on well-known prefix.
Is it routable prefix in global internet?  I don't believe so. ;-)

Comment on referrals.
If a user in ISP-B contacts to SIP service of ISP-A and got synthetic address
with the local prefix of ISP-A, the user should send the packet to the translator 
of ISP-A. Because the user is already authorized by SIP service of  ISP-A directly or indirectly. 
Yes, ISP-A may charge for the traffic, but it is already accepted.

In general, I think the synthetic address builder(in this case ISP-A) should take 
responsibility on the packet sent to the address.
If ISP-A and ISP-B collaborate to integrate the translation service, they may choose 
a common pref64 to optimize the traffic. In this case both are taking the responsibility.

Best Regards,

------------------------------------
Hiroshi Miyata,
Ubiquitous Field Computing Research Center,
Corporate R&D Headquaters,
Yokogawa Electric Corp.

> [mailto:[email-masked]] On Behalf Of Dan Wing
> Sent: Tuesday, February 24, 2009 8:16 AM
> To: 'marcelo bagnulo braun'
> > >>>>> synthetic IPv6 address to an IPv6 host belonging to 
> another ISP 
> > >>>>> will not work (an ISP is unlikely to operate NAT64 
> devices for 
> > >>>>> the benefit of any IPv6 host on the Internet that 
> wants to use 
> > >>>>> it).
> > >>>>>   
> > >>>>>       
> > >>>>>           
> > >>>> but, if you use the well know prefix this owuld work, 
> cause the 
> > >>>> traffic would flow through the NAT64 located in each 
> ISP, right?
> > >>>>     
> > >>>>         
> > >>> work once an ISP installs a NAT64 (or the subscriber 
> has some way 
> > >>> to use someone else's NAT64, perhaps via a tunnel and a 
> per-month 
> > >>> fee, for example).  But my point is that existing IPv6 
> hosts and 
> > >>> existing dual-stack hosts, in another ISP, cannot utilize a 
> > >>> synthetic address.
> > >>>
> > >>>   
> > >>>       
> > >> I mean this stuff doesn't work when your IPv6 ISP 
> doesn't provide 
> > >> their customer with IPv4 Internet access (i.e it doesn't 
> provide a
> > >> NAT64) and
> > >> referrals to the IPv4 internet break, any communication 
> towards the 
> > >> IPv4 internet break, cause he is not paying for that service
> > >>     
> > >
> > > dual-stack host, until/unless that dual-stack host's ISP 
> operates a 
> > > NAT64.  And that will not make sense to someone operating a 
> > > dual-stack host -- they will expect referrals to work 
> because they 
> > > are doing The Right Thing:  namely, operating a dual-stack host.
> > >
> > > I'll write this all up into an I-D which will hopefully make more 
> > > sense.
> > >
> > >   
> both the v6 and v4 Internet).  However, Host B's ISP has not 
> installed a NAT64 device -- at least, not "yet".  Perhaps 
> will only ever install a NAT44 (in order to continue 
> expanding their business after IPv4 exhaustion).  Whatever 
> the reason, Host B's ISP does not operate a NAT64.  Host B is 
> running today's dual-stack OS (pick your favorite) and some 
> dual- stack capable stack.  If Host B (dual-stack) is 
> referred to the synthetic IPv6 address for Host C 
> (IPv4-only), Host B can't do anything useful -- it cannot 
> communicate with Host C.  "One Would Expect" that Host B 
> could communicate with Host C, though -- afterall, both of 
> them are accessible over IPv4.
> 
> Resolutions include:
> There is another interesting scenario, though, using another 
> host, Host D with is IPv4 only.
> 
> If the referral is to Host D (IPv4 only), we cannot hope to 
> refer an IPv6 address to Host D.  We can only successful 
> NAT64 host sends a referral to either an IPv4-only host or to 
> a dual-stack host, the referral fails.
> 
>

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 23 Feb 2009 16:50:49 -0800

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, February 23, 2009 4:34 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [BEHAVE] Pref64 nature and referral support.
> 
> Dan and Marcelo,
> 

That would require some sort of interface between the ISP-A's NAT64 
device and the its SIP proxy/B2BUA/SBC, in order to authorize the
referral.  We could do that, I suppose.  But what of referrals
where some other ISP's SIP service is being utilized -- for example,
Vonage?  In that case, Vonage's SIP proxies will not be able to
tell ISP-A's NAT64 to allow the packets through.

-d

> > =

---

From: <[email-masked]>
Date: Tue, 24 Feb 2009 10:54:59 +0900

Dan,

> From: Dan Wing [mailto:[email-masked]] 
> Sent: Tuesday, February 24, 2009 9:51 AM
> To: Miyata, Hiroshi ([email-masked]); [email-masked]
> > If a user in ISP-B contacts to SIP service of ISP-A and got 
> synthetic 
> > address with the local prefix of ISP-A, the user should send the 
> > packet to the translator of ISP-A. Because the user is already 
> > authorized by SIP service of  ISP-A directly or indirectly.
> That would require some sort of interface between the ISP-A's 
> NAT64 device and the its SIP proxy/B2BUA/SBC, in order to 
> authorize the referral.  We could do that, I suppose.  
> But 
> what of referrals where some other ISP's SIP service is being 
> utilized -- for example, Vonage?  In that case, Vonage's SIP 
> proxies will not be able to tell ISP-A's NAT64 to allow the 
> packets through.
> 

Actually, my point is it works if the ISP designed to make it work.
As you mentioned the interface definition is required in most case.
So, I would like to say, this case can not be the reason to promote 
well-known address.

To answer to your question, the asspmption come from original
referral discussion with my understanding, maybe a long time ago.
In most case SIP sevice would not work with deep cooperation.
So, the case "referal works but traffic is dropped"
unlikely happen in SIP service, I think.

Sorry for your confusion.

Regards,

....hiroshi miyata

> > In general, I think the synthetic address builder(in this 
> case ISP-A) 
> > should take responsibility on the packet sent to the address.
> > If ISP-A and ISP-B collaborate to integrate the translation 
> service, 
> > they may choose a common pref64 to optimize the traffic. In 
> this case 
> > both are taking the responsibility.
> 
> -d
> 
> > Best Regards,
> > 
> > Ubiquitous Field Computing Research Center, Corporate R&D 
> Headquaters, 
> > Yokogawa Electric Corp.
> > 
> >  
> > 
> > > No; Host B is dual-stack and fully-functioning (can 
> access both the 
> > > v6 and v4 Internet).  However, Host B's ISP has not installed a 
> > > NAT64 device -- at least, not "yet".  Perhaps Host B's ISP never 
> > > will, because Host B's ISP believes that dual-stack hosts are the 
> > > right answer.  Perhaps Host B's ISP will only ever 
> install a NAT44 
> > > (in order to continue expanding their business after IPv4 
> > > exhaustion).  Whatever the reason, Host B's ISP does not 
> operate a 
> > > NAT64.  Host B is running today's dual-stack OS (pick 
> your favorite) 
> > > and some
> > > dual- stack capable stack.  If Host B (dual-stack) is referred to 
> > > the synthetic IPv6 address for Host C (IPv4-only), Host B 
> can't do 
> to refer an 
> > > IPv6 address to Host D.  We can only successful refer an IPv4 
> > > address to an IPv4 only host.
> > > 
> > > To my analysis, if we want referrals to work across a 
> NAT64, we need 
> > > to do (2), above -- namely, the host behind a NAT64 has to remove 
> > > the synthetic IPv6 address prior to referring the address.  
> > > Otherwise as soon as an IPv6-only host behind a
> > > NAT64 host sends a referral to either an IPv4-only host or to a 
> > > dual-stack host, the referral fails.
> > > 
> > > 
> > > > So, host A passes the IPv6 representation of Host C 
> IPv4 address 
> > > > to Host B.
> > > > Host B could access to Host C if it used the IPv4 
> address, but it 
> > > > cannot reach host C using the IPv6 representation cause 
> its ISP is 
> > > > not providing NAT64 services, is that what you had in mind?
> > > > 
> > > > known prefix is used, that the IPv6 address it has 
> received is an 
> > > > IPv6 representation of an IPv4 address and use IPv4 connectivity
> > > directly.
> > > >
> > > > much better, cause you can easily recognize that this is a 
> > > > represenation of an IPv4 address
> > > > 
> > > > Regards, marcelo
> > > > 
> > > > 
> > > > 
> > > > > -d
> > > > >
> > > > >
> > > > >

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 23 Feb 2009 18:05:50 -0800

> Sent: Monday, February 23, 2009 5:55 PM
> > > So, the routing information and identification should be 
> discussed 
> > > separately.
> > > 

That is the conclusion I believe I am reaching as I write the
I-D, too.

-d

> referred to