headers
Xing Li | 1 Jun 2009 08:06
Picon
Favicon

Re: interim meeting minutes


Iljitsch van Beijnum 写道:
> On 30 mei 2009, at 11:25, Xing Li wrote:
>
>> NAT64 (stateful and stateless)
>> NAT46 (stateful and stateless)
>
> In the stateless case NAT64 and NAT46 are the same.
>
> I would prefer to keep "NAT" for stateful unless specifically 
> indicated that it's stateless. We could keep SIIT for stateless 
> translation.
SIITbis? since it is different from the original SIIT.

xing
>
>
_______________________________________________
Behave mailing list
Behave <at> ietf.org
https://www.ietf.org/mailman/listinfo/behave
Permalink | Reply | 2 comments |
headers
Iljitsch van Beijnum | 1 Jun 2009 17:36
Favicon

Re: interim meeting minutes

On 1 jun 2009, at 8:06, Xing Li wrote:

>> I would prefer to keep "NAT" for stateful unless specifically  
>> indicated that it's stateless. We could keep SIIT for stateless  
>> translation.

> SIITbis? since it is different from the original SIIT.

Well, we usually call BGP4 "BGP" and HTTP/1.1 "HTTP", so I don't see a  
problem simply using "SIIT" unless we specifically need to point out  
that we're talking about the updated version.

We may want to avoid making a version 2 of NAT64 because NAT642 would  
be a bit confusing...

Iljitsch
Permalink | Reply | 1 comment |
headers
Rémi Després | 1 Jun 2009 19:08
Picon
Favicon

Re: interim meeting minutes - NAT64 definition


Le 30 mai 09 à 17:14, marcelo bagnulo braun a écrit :

> I personally think that the common understanding of the word NAT  
> todya is a device that is statefull and translates  not only  
> addresses but also ports.

Although it is true that most existing NATs are stateful, i.e. are  
NAPTs, I don't believe NAT is  "commonly understood" as only  
stateful. For example:
- In RFC 2663, a NAT is either stateless ("Basic NAT") or stateful  
(NAPT)
- In Margaret Wasserman's proposed IPv6 NAT,  NAT66 stands for a  
stateless function.

> for that reason, i believe that using the expression NAT64 and  
> NAT46 highlight the main difference with current NATs, i.e. that  
> they translate IPv6 to and from IPv4 and in the case of 64 they  
> support communications iniciated from the IPv6 side and in the case  
> of 46 they support communications initiated from the IPv4 side.

There can be NAT64s that are stateless,  with IPv4 addresses derived  
from IPv6 internal addresses.
"NAPT64" can name unambiguously what you propose to call NAT64.

> I think that the stateless translator is a very different device  
> from the most common version of IPv4 nats, since they are  
> stateless, so i think it makes sense to name it with a different  
> name that highlights the fact that they are stateless. I think  
> SIIT, stateless translator, even stateless IPv4/IPv6 translators
(Continue reading)

Permalink | Reply | 5 comments |
headers
Tow, Agnes C (Agnes)** CTR ** | 1 Jun 2009 20:31
Favicon

Re: Plan for IPv4/IPv6 translation documents

Fred,

What is the status of the proposed drafts listed in your email? They are
still not listed under the BEHAVE working group documents.

Thanks.
Agnes  

-----Original Message-----
From: behave-bounces <at> ietf.org [mailto:behave-bounces <at> ietf.org] On Behalf
Of Fred Baker
Sent: Wednesday, March 25, 2009 3:05 PM
To: Behave Chairs
Cc: Behave WG
Subject: [BEHAVE] Plan for IPv4/IPv6 translation documents

Referring to the October discussion and the chair's slides yesterday,  
and further to private email among the framework authors, the chairs,  
and Magnus yesterday and today, I want to capture what I understand to  
be the documentation plan. If I have it wrong, I would like to know  
that now; if I have it right I am already in process and want  
confirmation of the fact.

One thing discussed privately is that the reference from the  
translation document to the prefix is normative, which means that the  
document referred to should be standards track. You asked me to pull  
the prefix into a separate document.

So I understand that we have six documents called for at this point,  
with possible future ALG documents, for which I am suggesting
(Continue reading)

Permalink | Reply | 0 comments |
headers
Xing Li | 2 Jun 2009 01:11
Picon
Favicon

Re: The fragmentation issue


   Here are the algorithms currently implemented in a stateless
   translator (IVI), which works fine in the day-to-day operation.

   xing

         From IPv6 to IPv4:
         ----------------------------------------------------------
                         |     IPv6          |       IPv4
         ----------------------------------------------------------
         MTU             |     1500          |       1500
         ----------------------------------------------------------
         Fragmentation   |     DF=1          |   No ICMPv6 action.
         Handling        |                   |   Set DF=0 if the
                         |                   |   IPv6 packet is
                         |                   |   smaller than 1280
                         |                   |   and set DF=1 if
                         |                   |   the IPv6 packet
                         |                   |   is larger than
                         |                   |   1280.
                         ------------------------------------------
                         | Fragmentation     |   Fragmented
                         | header extension  |   packets
         ----------------------------------------------------------
         ICMP handling   | ICMPv6 (packet    |   ICMP (packet too
                         | too big)          |   big, the original
                         |                   |   advertised MTU-20)
         ----------------------------------------------------------

                        Figure 1: From IPv6 to IPv4
(Continue reading)

Permalink | Reply | 4 comments |
headers
Xing Li | 2 Jun 2009 01:14
Picon
Favicon

Re: interim meeting minutes


Iljitsch van Beijnum 写道:
> On 1 jun 2009, at 8:06, Xing Li wrote:
>
>>> I would prefer to keep "NAT" for stateful unless specifically 
>>> indicated that it's stateless. We could keep SIIT for stateless 
>>> translation.
>
>> SIITbis? since it is different from the original SIIT.
>
> Well, we usually call BGP4 "BGP" and HTTP/1.1 "HTTP", so I don't see a 
> problem simply using "SIIT" unless we specifically need to point out 
> that we're talking about the updated version.
so it is SIITbis, but we can just call it SIIT.
>
> We may want to avoid making a version 2 of NAT64 because NAT642 would 
> be a bit confusing...

understood. or NAT64bis?

xing
>
> Iljitsch
>
>
_______________________________________________
Behave mailing list
Behave <at> ietf.org
https://www.ietf.org/mailman/listinfo/behave
(Continue reading)

Permalink | Reply | 0 comments |
headers
teemu.savolainen | 2 Jun 2009 10:43
Picon

I-D Action:draft-denis-icmpv6-generation-for-teredo-00.txt

Behave WG,

We have submitted a new I-D that relates to the ongoing protocol translator work.

All comments are very welcome.
	
	Teemu

----------

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Generation of ICMPv6 Echo Replies for Teredo Clients
	Author(s)       : T. Savolainen, R. Denis-Courmont
	Filename        : draft-denis-icmpv6-generation-for-teredo-00.txt
	Pages           : 6
	Date            : 2009-05-28

Teredo uses return routing to discover the closest Teredo relay
corresponding to any given peer.  Discovery is achieved by sending an
ICMPv6 Echo Request and waiting for the appropriate relay to forward
the ICMPv6 Echo Reply back.  Unanswered ICMPv6 Echo Requests make
Teredo clients assume that the peer is unreachable.  This document
identifies two scenarios where a middlebox should detect the lack of
ICMPv6 Echo Reply and craft one toward the Teredo client in order to
avoid possibly erroneous peer unreachability assumptions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-denis-icmpv6-generation-for-teredo-00.txt
(Continue reading)

Permalink | Reply | 0 comments |
headers
marcelo bagnulo braun | 2 Jun 2009 10:13
Picon

Re: interim meeting minutes - NAT64 definition

Rémi Després escribió:
>
> Le 30 mai 09 à 17:14, marcelo bagnulo braun a écrit :
>
>> I personally think that the common understanding of the word NAT 
>> todya is a device that is statefull and translates  not only 
>> addresses but also ports.
>
> Although it is true that most existing NATs are stateful, i.e. are 
> NAPTs, I don't believe NAT is  "commonly understood" as only stateful. 
> For example:
> - In RFC 2663, a NAT is either stateless ("Basic NAT") or stateful (NAPT)
> - In Margaret Wasserman's proposed IPv6 NAT,  NAT66 stands for a 
> stateless function.
>
>> for that reason, i believe that using the expression NAT64 and NAT46 
>> highlight the main difference with current NATs, i.e. that they 
>> translate IPv6 to and from IPv4 and in the case of 64 they support 
>> communications iniciated from the IPv6 side and in the case of 46 
>> they support communications initiated from the IPv4 side.
>
> There can be NAT64s that are stateless,  with IPv4 addresses derived 
> from IPv6 internal addresses.
> "NAPT64" can name unambiguously what you propose to call NAT64.
>
>> I think that the stateless translator is a very different device from 
>> the most common version of IPv4 nats, since they are stateless, so i 
>> think it makes sense to name it with a different name that highlights 
>> the fact that they are stateless. I think SIIT, stateless translator, 
>> even stateless IPv4/IPv6 translators make sense.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Dave Thaler | 2 Jun 2009 23:14
Picon
Favicon

Comments on draft-xli-behave-v4v6-prefix-00.txt

Hi Xing Li,

 

Thanks again for writing up this draft.  I finally had time to type up my

personal comments on the currently posted version of this document. 

Some of them repeat things others already said.

 

-Dave Thaler

Attachment (draft-xli-behave-v4v6-prefix-00.pdf): application/pdf, 375 KiB
<div>

<div class="Section1">

<p class="MsoNormal">Hi Xing Li,<p></p></p>

<p class="MsoNormal"><p>&nbsp;</p></p>

<p class="MsoNormal">Thanks again for writing up this draft.&nbsp; I finally had time
to type up my <p></p></p>

<p class="MsoNormal">personal comments on the currently posted version of this
document.&nbsp; <p></p></p>

<p class="MsoNormal">Some of them repeat things others already said.<p></p></p>

<p class="MsoNormal"><p>&nbsp;</p></p>

<p class="MsoNormal">-Dave Thaler<p></p></p>

</div>

</div>
Permalink | Reply | 501 comments |
headers
Rémi Després | 3 Jun 2009 09:46
Picon
Favicon

Re: interim meeting minutes - NAT64 definition


Le 2 juin 09 à 10:13, marcelo bagnulo braun a écrit :

> Rémi Després escribió:
>>
>>>
>> If it can be accepted that stateful NAT64 is named NAPT64, we can  
>> get, quite naturally IMHO:
>>
>> NAT = NAT44, NAT64, or NAT46   (First and second digits are  
>> respectively those of internal and external address families. The  
>> NAT is sateless or stateful)
>> NAT44 = SIIT44 and/or NAPT44
>> NAT64 = SIIT64 and/or NAPT64
>> NAT46 = SIIT46 and/or NAPT46
>> NAT66 = SIIT66 and/or NAPT66
>
> imho, this is just too complex for people to use it
>
> From now, we are only working on stateless and statefull  
> translation, so, i would limit to define names for those and i  
> would go for SIIT and NAT64.

I see.
  Limiting so far to SIIT and *NAPT64*  would be fine as far as I am  
concerned.
(I understand that in some existing drafts have used NAT64 as meaning  
stateful only, but replacing NAT64 by NAPT64 in these documents   
should not be a big deal. On the contrary, limiting the acronym NAT  
to mean only stateful NATs  would be a change bound to create  
confusion.)

Regards,

RD
Permalink | Reply | 3 comments |

Gmane