Subject: [BEHAVE] Pref64 nature and referral support.

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 20 Jan 2009 12:33:37 +0100

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: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 20 Jan 2009 13:00:13 +0100

On 20 jan 2009, at 12:33, marcelo bagnulo braun wrote:

> 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 :-)

No, this happens all the time with BitTorrent. (By the way, the Pirate  
Bay just enabled IPv6 for their trackers and I did some testing, with  
less than favorable results: my not so recent BitTorrent clients  
wouldn't work anymore.)

Note though that the situation is even worse than what you outline,  
because the server may either learn peer 1's address from what peer 1  
says its address is, or from what it sees in the IP header in peer 1's  
packets. This gives us the following permutations with the peers (if  
they use v6) behind a NAT64:

Server trusts peer:

peer 1      peer 2      result
public v4   public v4   works
public v4   NAT         works
public v4   v6          works
NAT         public v4   fails
NAT         NAT         fails
NAT         v6          fails
v6          public v4   fails
v6          NAT         fails
v6          v6          WORKS

Server looks at header:

peer 1      peer 2      result
public v4   public v4   works
public v4   NAT         works
public v4   v6          works
NAT         public v4   works (with NAT traversal)
NAT         NAT         works (with NAT traversal)
NAT         v6          works (with NAT traversal)
v6          public v4   depends on whether NAT64 supports traversal
v6          NAT         depends on whether NAT64 supports traversal
v6          v6          depends on whether NAT64 supports traversal

So the second mechanism works in more cases but requires more extra  
mechanisms and makes v6-v6 communication go through a translator.

> version, they require a specific ALG

Isn't the policy to avoid ALGs?

A dual stack server would solve the v6-to-v6 case but for the v6-to-v4  
case the server would have to translate the IPv4 address into a  
pref64:: address so it would need to know the NAT64 prefix. That can  
only realistically work if the server is run by the same entity as the  
NAT64 (which could be the case in a fair number of VoIP deployments  
where the ISP runs the SIP gateway) or the pref64:: would have to be  
well-known.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Jan 2009 16:17:55 +1300

If a third party hears about a NATted address/port pair as a
referral, the NAT binding surely won't work for traffic to or
from that third party, in the general case?

    Brian

On 2009-01-21 01:00, Iljitsch van Beijnum wrote:
>> 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
> case the server would have to translate the IPv4 address into a pref64::
> address so it would need to know the NAT64 prefix. That can only
> realistically work if the server is run by the same entity as the NAT64
> (which could be the case in a fair number of VoIP deployments where the
> ISP runs the SIP gateway) or the pref64:: would have to be well-known.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 22 Jan 2009 13:36:09 +0100

> Iljitsch, I don't understand your "works" cases with NAT.

>> v6          v6          depends on whether NAT64 supports traversal

The point here is that the referral _can_ work because the server  
knows the correct address to give to a third party. It could still  
fail for NAT reasons. But if the server gives the third party 10.0.0.1  
the referral is dead in the water.

Another solution is that the server trusts the client, and the client  
tells the server its externally visible address. The advantage is that  
this can also work for the port, as the server can't deduce the port  
the third party should use from what it sees itself, like it can with  
the address.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 23 Jan 2009 10:21:08 -0800

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Wednesday, January 21, 2009 7:18 PM
> To: Iljitsch van Beijnum
> Cc: Behave WG
> Subject: Re: [BEHAVE] Pref64 nature and referral support.
> 

This is filtering behavior, and some IPv4 NATs do filter (block) packets that
arrive from a different host.  This is mentioned in RFC4787 with the following
text:

   REQ-8:  If application transparency is most important, it is
      RECOMMENDED that a NAT have an "Endpoint-Independent Filtering"
      behavior.  If a more stringent filtering behavior is most
      important, it is RECOMMENDED that a NAT have an "Address-Dependent
      Filtering" behavior.

      a) The filtering behavior MAY be an option configurable by the
         administrator of the NAT.

RFC4787 could only really describe current behavior and provide some guidance
because NAT products predated RFC4787 by about a decade.

I expect we could make stronger statements about the need for, and value of,
Endpoint-Independent Filtering in a NAT64 device.

-d

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 23 Jan 2009 19:43:03 +0100

> Endpoint-Independent Filtering in a NAT64 device.

but in order to support endpoint independent filtering the nat must have 
endpoint independent mapping and there is an open discussion about 
whether can afford that with the upcoming shortage of IPv4 addresses

is there any conclusion about this discussion?

Regards, marcelo

>>>> A referral operation is when a host A passes the IP 
>>>>         
>> address of a Host
>>     
>>>> 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 :-)
>>>>         
>>> No, this happens all the time with BitTorrent. (By the way, 
>>>       
>> the Pirate
>>     
>>> Bay just enabled IPv6 for their trackers and I did some 
>>>       
>> testing, with
>>     
>>> because the server may either learn peer 1's address from 
>>>       
>> what peer 1
>>     
>>> says its address is, or from what it sees in the IP header 
>>>       
>> in peer 1's
>>     
>>> A dual stack server would solve the v6-to-v6 case but for 
>>>       
>> the v6-to-v4
>>     
>>> case the server would have to translate the IPv4 address 
>>>       
>> into a pref64::
>>     
>>> realistically work if the server is run by the same entity 
>>>       
>> as the NAT64
>>     
>>> (which could be the case in a fair number of VoIP 
>>>       
>> deployments where the
>>     
>>> ISP runs the SIP gateway) or the pref64:: would have to be 
>>>       
>> well-known.
>>

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 23 Jan 2009 11:37:49 -0800

> nat must have endpoint independent mapping

True.

> and there is an open discussion about 

No.  

I am aware of draft-wing-behave-dynamic-tcp-port-reuse (now
expired), but I am not aware of a document that discusses Remi
Despres' proposal (I think it was Remi, sorry if I have that
wrong) to allow a NAT to purposefully do endpoint *dependent*
mapping for traffic to certain destination ports (e.g., TCP/80, 
UDP/53 and TCP/53).

As chair, I would certainly like to see documents that detail
such proposals.  A discussion of the trade-offs and benefits
would be valuable.

-d

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 24 Jan 2009 10:46:15 +1300

On 2009-01-24 08:37, Dan Wing wrote:
>> but in order to support endpoint independent filtering the 

Also, the address+port style of fractional IPv4 addresses
would cause extra difficulties in using referrals for any sort of
port-agile application, if you happened to hit an unholy mixture of
NAT64 and address+port usage. I fear that the dragons here are very
hard to conquer.

    Brian

---

From: Rémi Després <[email-masked]>
Date: Sat, 24 Jan 2009 11:07:19 +0100

Brian E Carpenter  -  le (m/j/a) 1/23/09 10:46 PM:
>>> but in order to support endpoint independent filtering the nat 
>>> must have endpoint independent mapping
>> True.
>> 
>>> and there is an open discussion about whether can afford that 
>>> with the upcoming shortage of IPv4 addresses
>>> 
>> Despres' proposal (I think it was Remi, sorry if I have that wrong)
>>  to allow a NAT to purposefully do endpoint *dependent* mapping for
>>  traffic to certain destination ports (e.g., TCP/80, UDP/53 and 
>> TCP/53).
Yes, I made this proposal in May 2008, and still believe it's worth
consideration.

AFAIK, the (minor) negative consequence would be that STUN servers,  if
they don't use their registered port 3478,  should at least avoid using
HTTP and DNS well known ports.

The (major) expected benefit, as IPv4 addresses become scarce, would be
that the address-multiplexing efficiency of NATs that do it  would be
much improved, especially on port 80.

>> 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 .

> 
> Also, the address+port style of fractional IPv4 addresses would cause
>  extra difficulties in using referrals for any sort of port-agile 
> application, if you happened to hit an unholy mixture of NAT64 and 
> address+port usage. I fear that the dragons here are very hard to 
> conquer.
Note that, i sec 3.2.3 of
http://tools.ietf.org/html/draft-despres-sam-01, the
proposed *port extended IPv4 addressing* uses only *dynamic ports* (49152 to
65535); Thus, interference with how NATs treat well known and registered
ports (0 to 49151) is avoided.

So far, I see no such unholy mixture, but agree that experiments are
needed to check that, with port extended IPv4 addressing, no unexpected
dragon gets out of a box .

Best regards,

RD

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 24 Jan 2009 14:45:45 +0100

Rémi Després escribió:
>>>> but in order to support endpoint independent filtering the nat must 
>>>> have endpoint independent mapping
>>> True.
>>>
>>>> and there is an open discussion about whether can afford that with 
>>>> the upcoming shortage of IPv4 addresses
>>>>
I think this approach is reasonable
We could be very conservative in the list of ports we accept address 
dependent mapping but as Remy says, even if we limit the list to port 80 
we would get significant gain imho

Regards, marcelo