internet-drafts | 7 Dec 15:24 2011
Picon

I-D Action: draft-ietf-behave-v4v6-bih-07.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item
of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF.

	Title           : Dual Stack Hosts Using "Bump-in-the-Host" (BIH)
	Author(s)       : Bill Huang
                          Hui Deng
                          Teemu Savolainen
	Filename        : draft-ietf-behave-v4v6-bih-07.txt
	Pages           : 29
	Date            : 2011-12-07

   Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 protocol
   translation mechanism that allows a class of IPv4-only applications
   that work through NATs to communicate with IPv6-only peers.  The host
   on which applications are running may be connected to IPv6-only or
   dual-stack access networks.  BIH hides IPv6 and makes the IPv4-only
   applications think they are talking with IPv4 peers by local
   synthesis of IPv4 addresses.  This document obsoletes RFC 2767 and
   RFC 3338.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-behave-v4v6-bih-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-v4v6-bih-07.txt

(Continue reading)

jouni korhonen | 9 Dec 11:13 2011
Picon

Re: tsv-dir review of draft-ietf-behave-nat64-learn-analysis-01


Haibin,

On Nov 11, 2011, at 3:18 AM, Songhaibin wrote:

>>> Another minor comment:
>>> 
>>> In section 4.6.1 , [I-D.boucadair-dhcpv6-shared-address-option] also support
>> NAT64 prefix allocation for building IPv4-embedded IPv6 address using DHCPv6
>> option. And this should be mentioned in the document.
>> 
>> Ok. Will add this.
>> 
> 
> Then I am okay with this draft.

Now that I made edits to the I-D I think the above is already covered in -01. The current text says:

   Section 4 of [I-D.boucadair-dhcpv6-shared-address-option] defines a
   DHCPv6 option that can be used to communicate to a requesting host
   the prefix used for building IPv4-Converted IPv6 addresses together
   with the format type and therefore also the used address synthesis
   algorithm.  Provisioning the format type is required so as to be
   correctly handled by the NAT64-enabled devices deployed in a given
   domain.

So we can convey the pref64 to the host, which can then use it to construct an ipv4-concerted ip6 address
(which is a variant of IPv4-embedded IPv6 addresses per RFC6052).

- Jouni
(Continue reading)

internet-drafts | 9 Dec 11:15 2011
Picon

I-D Action: draft-ietf-behave-nat64-learn-analysis-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item
of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF.

	Title           : Analysis of solution proposals for hosts to learn NAT64 prefix
	Author(s)       : Jouni Korhonen
                          Teemu Savolainen
	Filename        : draft-ietf-behave-nat64-learn-analysis-02.txt
	Pages           : 25
	Date            : 2011-12-09

   Hosts and applications may benefit from the knowledge if an IPv6
   address is synthesized, which would mean a NAT64 is used to reach the
   IPv4 network or Internet.  This document analyses a number of
   proposed solutions for communicating whether the synthesis is taking
   place, used address format, and the IPv6 prefix used by the NAT64 and
   DNS64.  The solutions enable both NAT64 avoidance and intentional
   utilization by allowing local IPv6 address synthesis.  The document
   concludes by recommending selection of heuristic discovery based
   solution.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-behave-nat64-learn-analysis-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat64-learn-analysis-02.txt

(Continue reading)

Dan Wing | 9 Dec 17:44 2011
Picon

FW: publication request, draft-ietf-behave-lsn-requirements-05

FYI

-----Original Message-----
From: Dan Wing [mailto:dwing <at> cisco.com] 
Sent: Friday, December 09, 2011 8:44 AM
To: 'iesg-secretary <at> ietf.org'
Cc: 'behave-chairs <at> tools.ietf.org';
'draft-ietf-behave-lsn-requirements <at> tools.ietf.org'
Subject: publishcation request, draft-ietf-behave-lsn-requirements-05

BEHAVE has finished with draft-ietf-behave-lsn-requirements-05, and 
requests publication.  Proto writeup below.

Thanks,
-d

-----

   (1.a)  Who is the Document Shepherd for this document? 

document: draft-ietf-behave-lsn-requirements-05
shepherd: Dan Wing, dwing <at> cisco.com

          Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?
Yes.

   (1.b)  Has the document had adequate review both from key WG members
(Continue reading)

Dan Wing | 19 Dec 19:33 2011
Picon

IETF82 minutes posted

Minutes for BEHAVE's meeting at IETF82 are now posted at
http://www.ietf.org/proceedings/82/minutes/behave.txt

Corrections to the minutes are accepted by IETF until January 
5th.  The chairs will need corrections a day or two before 
that deadline.

There was one comment during Alain Durand's SD-NAT presentation where 
we didn't get the speaker's name because the speaker didn't provide 
his name at the microphone.  If someone can help identify the 
speaker, it is at 137:30 into the recording at 
http://www.ietf.org/audio/ietf82/ietf82-3fbanquet-20111117-1506-am.mp3,
and minutes show:

  SD-NAT (Alain Durand)
  ---------------------
  ?: doesn't this break port randomization
  Alain: port randomization happens within the port block at the host/cpe

Thanks,
-d

internet-drafts | 20 Dec 09:35 2011
Picon

I-D Action: draft-ietf-behave-nat64-discovery-heuristic-04.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item
of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF.

	Title           : Discovery of a Network-Specific NAT64 Prefix using a Well-Known Name
	Author(s)       : Teemu Savolainen
                          Jouni Korhonen
	Filename        : draft-ietf-behave-nat64-discovery-heuristic-04.txt
	Pages           : 10
	Date            : 2011-12-20

   This document describes a method for detecting presence of DNS64 and
   for learning IPv6 prefix used for protocol translation on an access
   network without explicit support from the access network.  The method
   depends on existence of a well-known IPv4-only domain name
   "ipv4only.arpa".  The information learned enables applications and
   hosts to perform local IPv6 address synthesis and on dual-stack
   accesses avoid traversal through NAT64.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-heuristic-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-heuristic-04.txt

teemu.savolainen | 20 Dec 09:42 2011
Picon

Re: I-D Action: draft-ietf-behave-nat64-discovery-heuristic-04.txt

Hi all,

Here is a revision that uses "ipv4only.arpa" as the well-known IPv4-only domain name and introduces text
for secure NAT64 prefix discovery (section 3.1), which is essentially what Dan has proposed earlier. The
discovery text also notes there could be multiple prefixes in use, and hence there could be one or more AAAA
records per one or more NAT64 FQDN.

Also some clarifications here and there.

Best regards,

        Teemu

> -----Original Message-----
> From: behave-bounces <at> ietf.org [mailto:behave-bounces <at> ietf.org] On Behalf
> Of ext internet-drafts <at> ietf.org
> Sent: 20. joulukuuta 2011 10:36
> To: i-d-announce <at> ietf.org
> Cc: behave <at> ietf.org
> Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-
> 04.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Behavior Engineering for Hindrance Avoidance
> Working Group of the IETF.
>
>       Title           : Discovery of a Network-Specific NAT64 Prefix using a Well-
> Known Name
>       Author(s)       : Teemu Savolainen
(Continue reading)

John Selbie | 22 Dec 22:17 2011

(no subject)

In regards to the NAT mapping test described in RFC 5780, section 4.3.

If I read the RFC correctly:

Test 1 - binding request to Primary IP and Primary Port (stun1.mydomain.com:3478)
If no NAT detected, then stop, otherwise perform test 2.

Test 2 - binding request to Alternate IP and Primary Port (stun2.mydomain.com:3478)
If port mapping from test 1 is the same, then infer "endpoint-indepenent", otherwise test 3

Test 3 - binding request to Alternate IP and Alternate Port (stun2.mydomain.com:3479)
   Infer either "address dependent" or "address+port dependent" mapping based on result

I am curious about this.  But it seems like if test 2 and test 3 should be swapped. Such that test 2 was the one that hits the alternate port on the alternate IP.  And if the result was the same as test 1, then that would be more reliable to infer "endpoint independent" mapping than just comparing the two test results against identical port numbers on different IPs. 

Otherwise, as the test sequence stands now, it implies that there could never be "port dependent mapping".

Thoughts?

John Selbie



4.3.  Determining NAT Mapping Behavior

   This will require at most three tests.  In test I, the client
   performs the UDP connectivity test.  The server will return its
   alternate address and port in OTHER-ADDRESS in the binding response.
   If OTHER-ADDRESS is not returned, the server does not support this
   usage and this test cannot be run.  The client examines the XOR-
   MAPPED-ADDRESS attribute.  If this address and port are the same as
   the local IP address and port of the socket used to send the request,
   the client knows that it is not NATed and the effective mapping will
   be Endpoint-Independent.

   In test II, the client sends a Binding Request to the alternate
   address, but primary port.  If the XOR-MAPPED-ADDRESS in the Binding
   Response is the same as test I the NAT currently has Endpoint-
   Independent Mapping.  If not, test III is performed: the client sends
   a Binding Request to the alternate address and port.  If the XOR-
   MAPPED-ADDRESS matches test II, the NAT currently has Address-
   Dependent Mapping; if it doesn't match it currently has Address and
   Port-Dependent Mapping.

<div><p>In regards to the NAT mapping test described in RFC 5780, section 4.3.<br><br>If I read the RFC correctly:<br><br>Test 1 - binding request to Primary IP and Primary Port (<a href="http://stun1.mydomain.com:3478">stun1.mydomain.com:3478</a>)<br>
If no NAT detected, then stop, otherwise perform test 2.<br><br>Test 2 - binding request to Alternate IP and Primary Port (<a href="http://stun2.mydomain.com:3478">stun2.mydomain.com:3478</a>)<br>If port mapping from test 1 is the same, then infer "endpoint-indepenent", otherwise test 3<br><br>Test 3 - binding request to Alternate IP and Alternate Port (<a href="http://stun2.mydomain.com:3479">stun2.mydomain.com:3479</a>)<br>&nbsp;&nbsp; Infer either "address dependent" or "address+port dependent" mapping based on result<br><br>I am curious about this.&nbsp; But it seems like if test 2 and test 3 should be swapped. Such that test 2 was the one that hits the alternate port on the alternate IP.&nbsp; And if the result was the same as test 1, then that would be more reliable to infer "endpoint independent" mapping than just comparing the two test results against identical port numbers on different IPs.&nbsp; <br><br>Otherwise, as the test sequence stands now, it implies that there could never be "port dependent mapping".<br><br>Thoughts?<br><br>John Selbie<br><br><br><br>4.3.&nbsp; Determining NAT Mapping Behavior<br><br>&nbsp;&nbsp; This will require at most three tests.&nbsp; In test I, the client<br>
&nbsp;&nbsp; performs the UDP connectivity test.&nbsp; The server will return its<br>&nbsp;&nbsp; alternate address and port in OTHER-ADDRESS in the binding response.<br>&nbsp;&nbsp; If OTHER-ADDRESS is not returned, the server does not support this<br>&nbsp;&nbsp; usage and this test cannot be run.&nbsp; The client examines the XOR-<br>
&nbsp;&nbsp; MAPPED-ADDRESS attribute.&nbsp; If this address and port are the same as<br>&nbsp;&nbsp; the local IP address and port of the socket used to send the request,<br>&nbsp;&nbsp; the client knows that it is not NATed and the effective mapping will<br>
&nbsp;&nbsp; be Endpoint-Independent.<br><br>&nbsp;&nbsp; In test II, the client sends a Binding Request to the alternate<br>&nbsp;&nbsp; address, but primary port.&nbsp; If the XOR-MAPPED-ADDRESS in the Binding<br>&nbsp;&nbsp; Response is the same as test I the NAT currently has Endpoint-<br>
&nbsp;&nbsp; Independent Mapping.&nbsp; If not, test III is performed: the client sends<br>&nbsp;&nbsp; a Binding Request to the alternate address and port.&nbsp; If the XOR-<br>&nbsp;&nbsp; MAPPED-ADDRESS matches test II, the NAT currently has Address-<br>&nbsp;&nbsp; Dependent Mapping; if it doesn't match it currently has Address and<br>
&nbsp;&nbsp; Port-Dependent Mapping.<br></p></div>
John Selbie | 22 Dec 22:20 2011

RFC 5780 - Order of mapping tests

<adding subject header - sorry for dupe>

In regards to the NAT mapping test described in RFC 5780, section 4.3.

If I read the RFC correctly:

Test 1 - binding request to Primary IP and Primary Port (stun1.mydomain.com:3478)
If no NAT detected, then stop, otherwise perform test 2.

Test 2 - binding request to Alternate IP and Primary Port (stun2.mydomain.com:3478)
If port mapping from test 1 is the same, then infer "endpoint-indepenent", otherwise test 3

Test 3 - binding request to Alternate IP and Alternate Port (stun2.mydomain.com:3479)
   Infer either "address dependent" or "address+port dependent" mapping based on result

I am curious about this.  But it seems like if test 2 and test 3 should be swapped. Such that test 2 was the one that hits the alternate port on the alternate IP.  And if the result was the same as test 1, then that would be more reliable to infer "endpoint independent" mapping than just comparing the two test results against identical port numbers on different IPs. 

Otherwise, as the test sequence stands now, it implies that there could never be "port dependent mapping".

Thoughts?

John Selbie

4.3.  Determining NAT Mapping Behavior

   This will require at most three tests.  In test I, the client
   performs the UDP connectivity test.  The server will return its
   alternate address and port in OTHER-ADDRESS in the binding response.
   If OTHER-ADDRESS is not returned, the server does not support this
   usage and this test cannot be run.  The client examines the XOR-
   MAPPED-ADDRESS attribute.  If this address and port are the same as
   the local IP address and port of the socket used to send the request,
   the client knows that it is not NATed and the effective mapping will
   be Endpoint-Independent.

   In test II, the client sends a Binding Request to the alternate
   address, but primary port.  If the XOR-MAPPED-ADDRESS in the Binding
   Response is the same as test I the NAT currently has Endpoint-
   Independent Mapping.  If not, test III is performed: the client sends
   a Binding Request to the alternate address and port.  If the XOR-
   MAPPED-ADDRESS matches test II, the NAT currently has Address-
   Dependent Mapping; if it doesn't match it currently has Address and
   Port-Dependent Mapping.


<div><p>&lt;adding subject header - sorry for dupe&gt;<br><br>In regards to the NAT mapping test described in RFC 5780, section 4.3.<br><br>If I read the RFC correctly:<br><br>Test 1 - binding request to Primary IP and Primary Port (<a href="http://stun1.mydomain.com:3478/" target="_blank">stun1.mydomain.com:3478</a>)<br>

If no NAT detected, then stop, otherwise perform test 2.<br><br>Test 2 - binding request to Alternate IP and Primary Port (<a href="http://stun2.mydomain.com:3478/" target="_blank">stun2.mydomain.com:3478</a>)<br>If port mapping from test 1 is the same, then infer "endpoint-indepenent", otherwise test 3<br><br>Test 3 - binding request to Alternate IP and Alternate Port (<a href="http://stun2.mydomain.com:3479/" target="_blank">stun2.mydomain.com:3479</a>)<br>&nbsp;&nbsp; Infer either "address dependent" or "address+port dependent" mapping based on result<br><br>I am curious about this.&nbsp; But it seems like if test 2 and test 3 
should be swapped. Such that test 2 was the one that hits the alternate 
port on the alternate IP.&nbsp; And if the result was the same as test 1, 
then that would be more reliable to infer "endpoint independent" mapping
 than just comparing the two test results against identical port numbers
 on different IPs.&nbsp; <br><br>Otherwise, as the test sequence stands now, it implies that there could never be "port dependent mapping".<br><br>Thoughts?<br><br>John Selbie<br><br>4.3.&nbsp; Determining NAT Mapping Behavior<br><br>&nbsp;&nbsp; This will require at most three tests.&nbsp; In test I, the client<br>
&nbsp;&nbsp; performs the UDP connectivity test.&nbsp; The server will return its<br>&nbsp;&nbsp; alternate address and port in OTHER-ADDRESS in the binding response.<br>&nbsp;&nbsp; If OTHER-ADDRESS is not returned, the server does not support this<br>&nbsp;&nbsp; usage and this test cannot be run.&nbsp; The client examines the XOR-<br>
&nbsp;&nbsp; MAPPED-ADDRESS attribute.&nbsp; If this address and port are the same as<br>&nbsp;&nbsp; the local IP address and port of the socket used to send the request,<br>&nbsp;&nbsp; the client knows that it is not NATed and the effective mapping will<br>
&nbsp;&nbsp; be Endpoint-Independent.<br><br>&nbsp;&nbsp; In test II, the client sends a Binding Request to the alternate<br>&nbsp;&nbsp; address, but primary port.&nbsp; If the XOR-MAPPED-ADDRESS in the Binding<br>&nbsp;&nbsp; Response is the same as test I the NAT currently has Endpoint-<br>
&nbsp;&nbsp; Independent Mapping.&nbsp; If not, test III is performed: the client sends<br>&nbsp;&nbsp; a Binding Request to the alternate address and port.&nbsp; If the XOR-<br>&nbsp;&nbsp; MAPPED-ADDRESS matches test II, the NAT currently has Address-<br>&nbsp;&nbsp; Dependent Mapping; if it doesn't match it currently has Address and<br>
&nbsp;&nbsp; Port-Dependent Mapping.<br><br><br></p></div>
internet-drafts | 23 Dec 08:23 2011
Picon

I-D Action: draft-ietf-behave-v4v6-bih-08.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item
of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF.

	Title           : Dual Stack Hosts Using "Bump-in-the-Host" (BIH)
	Author(s)       : Bill Huang
                          Hui Deng
                          Teemu Savolainen
	Filename        : draft-ietf-behave-v4v6-bih-08.txt
	Pages           : 29
	Date            : 2011-12-22

   Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 protocol
   translation mechanism that allows a class of IPv4-only applications
   that work through NATs to communicate with IPv6-only peers.  The host
   on which applications are running may be connected to IPv6-only or
   dual-stack access networks.  BIH hides IPv6 and makes the IPv4-only
   applications think they are talking with IPv4 peers by local
   synthesis of IPv4 addresses.  This document obsoletes RFC 2767 and
   RFC 3338.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-behave-v4v6-bih-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-v4v6-bih-08.txt


Gmane