Subject: [BEHAVE] comment about draft-wing-behave-nat64-referrals-00.txt

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 08 Mar 2009 10:32:15 +0100

Hi,

been through this document and i have a comment:

section 2.2.  BitTorrent reads

   BitTorrent trackers use HTTP URIs and DNS names.  Thus, if an IPv6-
   only host running a web browser can connect to an IPv4-only web site
   using a translator (e.g., using NAT64 and DNS64), that same IPv6-only
   host running a BitTorrent client can connect to an IPv4-only
   BitTorrent tracker.  While some BitTorrent trackers are beginning to
   track IPv6 addresses of BitTorrent peers, most trackers only track
   IPv4 peers.  Most content is only available on IPv4.

   When an IPv6-only BitTorrent peer obtains IPv4 addresses from its
   tracker, it cannot use those IPv4 addresses.  To do so, the
   BitTorrent client software would need to prefix the IPv4 address with
   the prefix of a NAT64 that will perform the necessary address family
   translation on behalf of the IPv6-only BitTorrent client.  This could
   be done with updates to BitTorrent clients to prefix the IPv4 address
   with the IPv6 prefix of a NAT64 translator which will both authorize
   and route the communication to the IPv4 BitTorrent peer.  BitTorrent
   clients do not perform this function today.

I agree with that, but suppose you upgrade the bittorrent to do this 
(which probably will happen if more content is available in IPv6)

Which would be easier to handle, the well known prefix or the lir prefix?

With the well known prefix, the the bittorrent client could simply 
hardcode the well know prefix and if it detects it is on an ipv6 only 
host, it can prepend the well know prefix and it may work. With the LIR 
prefix, the bittorrent client would need to learn the nat64 prefix in 
order to make any attempt at all.

makes sense?

regards, marcelo

---

From: <[email-masked]>
Date: Mon, 9 Mar 2009 08:28:29 +0100

Please see inline.
Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de marcelo bagnulo braun
Envoyé : dimanche 8 mars 2009 10:32
À : Dan Wing; Behave WG
Objet : [BEHAVE] comment about draft-wing-behave-nat64-referrals-00.txt

Hi,

I agree with that, but suppose you upgrade the bittorrent to do this (which probably will happen if more content is available in IPv6)

Med: for the application, it is easier to have a IANA assigned prefix..

With the well known prefix, the the bittorrent client could simply hardcode the well know prefix and if it detects it is on an ipv6 only host, it can prepend the well know prefix and it may work. With the LIR prefix, the bittorrent client would need to learn the nat64 prefix in order to make any attempt at all.

makes sense?

Med: This assumes the availability of inter-domain routes to reach those WK prefixes...

regards, marcelo

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

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 09 Mar 2009 08:58:07 +0100

> Med: This assumes the availability of inter-domain routes to reach those WK prefixes...
I don't think so
Please check draft-miyata-behave-prefix64-01.txt just posted, the 
section about referrals
The Well known prefix, is passed from one domain to another doamin in 
the referral.
Once it is received in the other domain, it is used. So, what is needed 
is that both the originator of the referral and that the receiver of the 
referral have translation services. But if they don't have translation 
services, the referral won't work in any case cause the IPv4 only host 
is no reachable

(this is a bit tricky to describe in a few setneces, so i reccomend you 
to check the referral section in the draft)

Regards, marcelo

---

From: <[email-masked]>
Date: Mon, 9 Mar 2009 09:20:15 +0100

Thank Marcelo for the pointer.

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : marcelo bagnulo braun [mailto:[email-masked]] 
Envoyé : lundi 9 mars 2009 08:58
À : BOUCADAIR Mohamed RD-CORE-CAE
Cc : [email-masked]; [email-masked]
Objet : Re: [BEHAVE] comment about draft-wing-behave-nat64-referrals-00.txt

[email-masked] escribió:
> De : [email-masked] [mailto:[email-masked]] De la 
> part de marcelo bagnulo braun Envoyé : dimanche 8 mars 2009 10:32 À : 
> Dan Wing; Behave WG Objet : [BEHAVE] comment about 
> draft-wing-behave-nat64-referrals-00.txt
>
> Hi,
>
I don't think so
Please check draft-miyata-behave-prefix64-01.txt just posted, the section about referrals The Well known prefix, is passed from one domain to another doamin in the referral.
Once it is received in the other domain, it is used. So, what is needed is that both the originator of the referral and that the receiver of the referral have translation services. But if they don't have translation services, the referral won't work in any case cause the IPv4 only host is no reachable

Med: I read that section. My point is that the "translation service" may not be connected to the same BGP domain as for the originator or the receiver. In this case, a routing issue may be raised when using a WK prefix, since no IP routes may be available. BT application *** can not *** ensure that a successful communication will be experienced even if the referral procedure is implemented.  

(this is a bit tricky to describe in a few setneces, so i reccomend you to check the referral section in the draft)

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 09 Mar 2009 09:51:11 +0100

> Med: I read that section. My point is that the "translation service" may not be connected to the same BGP domain as for the originator or the receiver. In this case, a routing issue may be raised w…
sure, i fully agree with that
But this has nothing to do with the referral operation
I mean, if the receiver of the referral is IPv6 only and has no access 
to the services of a translator, it means that it cannot communicate to 
IPv4 only hosts, right? (with or wihtout referrals)
So the problem for this host is much more general than the referal 
breaking, but all communications with IPv4 internet is breaking

I mean, it would be the same if a hots is unreachable cause it has no 
connectivity, a referal to that host won't work, right, but no 
communication would work, so not a specific problem of the referral.

In other words, if you want to evaluate if referrals work, you need to 
assume that that it is possible for the 3 host to exchange packet among 
them, If that condition does not hold, then, there is no connectivyt and 
even regular client server communication would break.

Makes sense?

regards, marcelo

---

From: <[email-masked]>
Date: Mon, 9 Mar 2009 10:08:58 +0100

> Please check draft-miyata-behave-prefix64-01.txt just posted, the
section about referrals The Well known prefix, is passed from one domain
to another doamin in the referral.
> Once it is received in the other domain, it is used. So, what is 
> needed is that both the originator of the referral and that the 
> receiver of the referral have translation services. But if they don't 
> have translation services, the referral won't work in any case cause 
> the IPv4 only host is no reachable
>
>
> Med: I read that section. My point is that the "translation service"
may not be connected to the same BGP domain as for the originator or the
receiver. In this case, a routing issue may be raised when using a WK
prefix, since no IP routes may be available. BT application *** can not
*** ensure that a successful communication will be experienced even if
the referral procedure is implemented.  

Med: So, you agree that when a WK prefix is used than it may not lead to
successful communications if implemented by BitTorrent..

But this has nothing to do with the referral operation I mean, if the
receiver of the referral is IPv6 only and has no access to the services
of a translator, it means that it cannot communicate to
IPv4 only hosts, right? (with or wihtout referrals) 

Med: Fully agree. And this is mainly the limitation of the referral
procedure in case of BT (or even SIP) when a hard coded prefix of the
translation service is used. 

Med: the problem of this node is that it is unable to discover a
**valid** translation service since it is biased by the "hard coded WK
IPv6 prefix".

Med: Fully agreed. But, things are more complicated because of the usage
of hard coded IPv6 prefix instead of dynamic discovery of translation
service. The point is that a WK prefix may be simple to be implemented
by application, but some complications may be raised such as routing
issues. Do you agree with this? 

Cheers
Med

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 09 Mar 2009 10:34:31 +0100

> translation service is used. 

it seems we are diverging...

I understood that you mentioned before that the receiver of the referral 
had no access to the translator services, so it has not access to the v4 
internet
it has nothing to do with the prefix being hardcoded.

> **valid** translation service since it is biased by the "hard coded WK

don't understand
could you make a picture or something to put an example of what you mean?

> service.
hardcoding a prefix allows dynamic discovery of the translation service.
what you don't need is to discover the rpefix used for that
but any box can annoucne the prefix and provide the services. Is like 
having a well known name for a service. You just send  packet to that 
naem and you know what service you will get

>  The point is that a WK prefix may be simple to be implemented
No
please provide a specific example of a complication on routing

Regards, marcelo

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 9 Mar 2009 11:56:56 -0700

> -----Original Message-----
> From: marcelo bagnulo braun [mailto:[email-masked]] 
> Sent: Sunday, March 08, 2009 1:32 AM
> To: Dan Wing; Behave WG
> Subject: comment about draft-wing-behave-nat64-referrals-00.txt
> 
> Hi,
> 

The need for such functionality in BitTorrent does not get created
when more content is available in IPv6.  Rather, the need occurs
when an IPv6-only BitTorrent client wants to access content that
is only available on an IPv4-only BitTorrent peer.

> order to make any attempt at all.

I will, of course, concede it is easier to hard-code a prefix than do a DNS
query. 

But learning the prefix is merely a DNS query (or DHCPINFORM, if you prefer),
as detailed in <http://tools.ietf.org/html/draft-wing-behave-learn-prefix-01>
which I updated today.  BitTorrent clients are already pretty complex it seems
reasonable to add a DNS query during the initialization of the BitTorrent
client, especially if doing that DNS query allows an IPv6-only BitTorrent
client to access content available on IPv4-only peers -- accessing content
from peers is the primary purpose of a BitTorrent client.

But the argument between well-known prefix and LIR prefix is not solely around
which one is easier for an application.  There are other considerations.

-d

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 09 Mar 2009 21:06:35 +0100

> from peers is the primary purpose of a BitTorrent client.
agree
moreover, in any case, both with WK and the LIR prefix, the BT needs to 
be updated (it would be very different if with one of the options 
existent clients could work, but unfortunatelly, it is not the case)

SO, i agree that if the BT client needs to be upated, either hardcofing 
the wk prefix or learning dynamically, doesn't change much
> which one is easier for an application.  There are other considerations.
agree
but the draft was discussing this one, hence the limited scope of this 
particular thread
regards, marcelo

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 9 Mar 2009 13:16:31 -0700

> Sent: Monday, March 09, 2009 12:58 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [BEHAVE] comment about 
> > De : [email-masked] 
> [mailto:[email-masked]] De la part de marcelo bagnulo braun
> > I agree with that, but suppose you upgrade the bittorrent 
> to do this (which probably will happen if more content is 
> available in IPv6)
> >
> > With the well known prefix, the the bittorrent client could 
> simply hardcode the well know prefix and if it detects it is 
> on an ipv6 only host, it can prepend the well know prefix and 
> it may work. With the LIR prefix, the bittorrent client would 
> need to learn the nat64 prefix in order to make any attempt at all.
> >
> > makes sense?
> >
> >

I just read it.  

That section of the draft assumes that IPv6 hosts and their applications
would always (and only?) be able to refer IPv6 addresses.  This is not
a necessary design.  In fact, that design will fail when those applications
provide a referral to an IPv4 host.  Being as almost every SIP user
agent and almost every BitTorrent peer are, today, on IPv4, this would
be a poor design decision for those applications when the application
is deployed on an IPv6-only host.

draft-miyata-behave-prefix64-01 has the following diagram:

                           |
    Host_A ---(ISP_A)---NAT64--\
                 |         |    >---Host_B (IPB)
    Host_C ---(ISP_B)---NAT64--/
                           |
                           |
        IPv6 Internet      |     IPv4 Internet

   Figure: Referral scenario #2 involving multiple NAT64 boxes

   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 on whether
   Pref64_1 is 96 bits long or shorter).

The problem is that, before sending the referral to Host-C, Host-A 
cannot know if Host-C is:

  1. running IPv6 at all (and could use the IPv6 address), or if
  2. dual-stack without a NAT64 (which is IETF's current recommend 
     practice), and able to use Host-B's IPv4 address directly, or if
  3. dual-stack with a NAT44 and without a NAT64.  Such a host would be 
     able to use Host-B's IPv4 address, but could not use the synthetic
     IPv6 address.

In all three of those cases, Host-C could make good use of Host-B's 
IPv4 address.  The corollary is also true:  in all three of those
cases, the IPv6 address is useless (no matter if well-known prefix
or LIR prefix) and the referral fails because communication cannot 
be established.

I think the difference in how draft-miyata-behave-prefix64 and 
draft-wing-behave-nat64-referrals describe IPv6/IPv4 referrals 
points out the underlying problem:  the IETF has been too vague in
guidance to applications for how referrals should work, and needs
to provide such guidance.

-d

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 09 Mar 2009 21:26:26 +0100

Dan Wing escribió:
>>> Objet : [BEHAVE] comment about 
>>>       
>>>    BitTorrent trackers use HTTP URIs and DNS names.  Thus, 
>>>       
>> if an IPv6-
>>     
>>>    only host running a web browser can connect to an 
>>>       
>> IPv4-only web site
>>     
>>>    using a translator (e.g., using NAT64 and DNS64), that 
>>>       
>> same IPv6-only
>>     
>>>    BitTorrent tracker.  While some BitTorrent trackers are 
>>>       
>> beginning to
>>     
>>>    track IPv6 addresses of BitTorrent peers, most trackers 
>>>       
>> only track
>>     
>>>    BitTorrent client software would need to prefix the IPv4 
>>>       
>> address with
>>     
>>>    the prefix of a NAT64 that will perform the necessary 
>>>       
>> address family
>>     
>>>    translation on behalf of the IPv6-only BitTorrent 
>>>       
>> client.  This could
>>     
>>>    be done with updates to BitTorrent clients to prefix the 
>>>       
>> IPv4 address
>>     
>>>    with the IPv6 prefix of a NAT64 translator which will 
>>>       
>> both authorize
>>     
>>>    and route the communication to the IPv4 BitTorrent peer. 
>>>       
>>  BitTorrent
>>     
>>> Which would be easier to handle, the well known prefix or 
>>>       
>> the lir prefix?
>>     
>>> Med: for the application, it is easier to have a IANA 
>>>       
>> assigned prefix..
>>     
>>> Med: This assumes the availability of inter-domain routes 
>>>       
>> to reach those WK prefixes...
>>     
>>>   
>>>       
>> I don't think so
right
Jari made this point and i have reflected this in a new version that i 
have submitted today (sorry about that)
It is already available in the repositories

> or LIR prefix) and the referral fails because communication cannot 
I think i agree.
Host A can either send the IPv4 address or the IPv6 representation of 
the IPv4 address.
If it sends that IPv6 representation of the address, the WK prefix could 
help, cause the other end could recognize it as such
If it sends the IPv4 address directly, then, it would also make sense 
for the receiving host, since it understnads IPv4

Now, maybe the most reasonable approach when referring an IPv4 address 
is to pass it directly and not to pass the IPv6 representation, even if 
the sender is an IPv6 only host. I can buy that. But wouldn't this 
assuming that apps will continue to support IPv4? this is certainly a 
reasonable assumption to make at this point, but will this hold in the 
future?

regards, marcelo

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 9 Mar 2009 15:09:14 -0700

> reasonable assumption to make at this point, but will this 
> hold in the future?

It's only important so long as there is an IPv6/IPv4 translation
device and a need for IPv6 hosts to communicate across the translator
to an IPv4 device.  Once the IPv6 transition is complete, these devices
would be removed and the IPv4-aware code in IPv6 BitTorrent clients
and in IPv6 SIP clients can be removed.

This appears to impact only SIP and BitTorrent.  

If IPv6 gives birth to a killer IPv6 application which does referrals,
that killer application will not need to interact with IPv4 nodes and 
will not need a NAT64.  So I don't forsee a future where we are 'stuck' 
with needing to understand IPv4 referrals when, in the future, someone
invents an IPv6 application that performs IPv6 referrals.

-d

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 10 Mar 2009 11:10:31 +0100

> This appears to impact only SIP and BitTorrent.
But there are millions of applications out that there that we don't 
don't know how they work
For instance, what about multiplayer games? Don't they do referrals? (i 
ahve no idea, but it seems a sceanrio that is complex enough to may need 
this)

My point is that while bitorrent and SIP are two celar cases, it is not 
obvious to me that they are the only ones

Regards, marcelo

> will not need a NAT64.

>   So I don't forsee a future where we are 'stuck'

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 10 Mar 2009 11:14:59 +0100

Dan Wing escribió:
> IPv4 address.

one more question about this...

how does Host A knows that Pref64_1:IPB:suffix is indeed a 
representation of an IPv4 address in IPv6?
In order to do that, it needs to know the prefix used for that
again, we are int he situation that host A needs to discover the 
prefix64 in order to identify this is a represetnation of an IPv4 
address in IPv6.
So the host A would need to implement the discover provedures if the LIR 
prefix is used

Regards, marcelo

>   The corollary is also true:  in all three of those

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Mar 2009 16:43:25 +1300

On 2009-03-10 23:14, marcelo bagnulo braun wrote:
...
> So the host A would need to implement the discover provedures if the LIR

Reading that and some earlier comments in this thread, it seems to me
that we might consider defining a generic 'referral object', containing
more information than just an address, that could be passed among
application entities. It could contain TLVs that would provide the
semantics of the referred address as well as the raw address bits.

Does this seem worth exploring?

     Brian

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 16 Mar 2009 22:05:26 -0700

> Does this seem worth exploring?

Yes, this could form the basis for very useful guidance to application
designers.  ICE does something like this already, but abstracting its
functions up several levels, as you propose, would be useful.

Something like:  "here is my IPv4 address, it goes through a 
translator so avoid using it if you can utilize my IPv6 address" 
and so on.

-d

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Mar 2009 16:44:37 +1300

> translator so avoid using it if you can utilize my IPv6 address" 

Yes, but make the format extensible. Unofficial bar BOF in SF?

   Brian

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 19 Mar 2009 15:04:36 -0700

> > designers.  ICE does something like this already, but 
> > abstracting its functions up several levels, as you propose, 
> > would be useful.
> > 

Yes, that would be valuable.

-d

---

From: <[email-masked]>
Date: Fri, 20 Mar 2009 09:21:20 +0100

Hi all,

FYI, in the context of SIP services, the proposed semantic may be supported by the atypes attribute as described in http://tools.ietf.org/html/draft-boucadair-sipping-ipv6-atypes-01.

In addition to the already defined values, the following ones may be supported:

- "here is my IPv4 address, it goes through a translator so avoid using it if you can utilize my IPv6 address" (D. Wing)
atypes="ipv6, ipv4_via_nat46"

- here is my IPv6 address, it goes through a translator so avoid using it if you can utilize my IPv4 address
atypes="ipv4, ipv6_via_nat64"

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Dan Wing
Envoyé : jeudi 19 mars 2009 23:05
À : 'Brian E Carpenter'
Cc : BOUCADAIR Mohamed RD-CORE-CAE; [email-masked]
Objet : Re: [BEHAVE] comment about draft-wing-behave-nat64-referrals-00.txt

> > Yes, this could form the basis for very useful guidance to 
> > application designers.  ICE does something like this already, but 
> > abstracting its functions up several levels, as you propose, would 
> > be useful.
> > 

-d