Subject: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-17.txt

From: [email-masked]
Date: Wed, 7 Apr 2010 01:00:01 -0700 (PDT)

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           : IP/ICMP Translation Algorithm
	Author(s)       : X. Li, et al.
	Filename        : draft-ietf-behave-v6v4-xlate-17.txt
	Pages           : 31
	Date            : 2010-04-07

This document forms a replacement of the Stateless IP/ICMP
Translation Algorithm (SIIT) described in RFC 2765.  The algorithm
translates between IPv4 and IPv6 packet headers (including ICMP
headers).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-behave-v6v4-xlate-17.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Ramji Vaithianathan (rvaithia)" <[email-masked]>
Date: Wed, 7 Apr 2010 01:55:42 -0700

Hi,

In the latest draft it is mentioned:

The translator MUST provide a configuration function to adjust the MTU	
			from a value smaller than 1280 to 1280, which is
required	
			for the workaround ([RFC2460] related issue)
discussed in	
			Section 4. 

What exactly does "configuration function" mean?

Does it mean that there MUST be a CLI configurable option in the
translator to adjust the value smaller than 1280 to 1280?

Or does it just mean that the translator must have the
functionality/capablity to adjust the MTU smaller than 1280 to 1280
always?

Thanks,

Ramji

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Wednesday, April 07, 2010 1:30 PM
To: [email-masked]
Cc: [email-masked]
Subject: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-17.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.

This document forms a replacement of the Stateless IP/ICMP Translation
Algorithm (SIIT) described in RFC 2765.  The algorithm translates
between IPv4 and IPv6 packet headers (including ICMP headers).

---

From: Xing Li <[email-masked]>
Date: Wed, 07 Apr 2010 17:13:38 +0800

> functionality/capablity to adjust the MTU smaller than 1280 to 1280
Yes, the translator must have the functionality/capablity to adjust the 
MTU smaller than 1280 to 1280 always.

Regards,

xing

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

---

From: Simon Perreault <[email-masked]>
Date: Wed, 07 Apr 2010 08:05:30 -0400

> MTU smaller than 1280 to 1280 always.

As an implementor, let met say that I don't understand what this means.

Does this mean the following?

if (config->mtu_floor && ntohl(icmp6->icmp6_mtu) < 1280)
         icmp6->icmp6_mtu = htonl(1280);

In this case, is there a recommended value for the configuration 
variable? Or does it really not matter?

Thanks,
Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

---

From: Xing Li <[email-masked]>
Date: Wed, 07 Apr 2010 22:04:40 +0800

> variable? Or does it really not matter?
Actually we mean:

The translator can be configured to enable or disable the function
{
if (ntohl(icmp6->icmp6_mtu) < 1280)
icmp6->icmp6_mtu = htonl(1280);
}

The detailed discussion is in Section 4 of the xlate draft.

Could you kindly give us some suggestions to make the presentation clearer?

Regards,

xing

---

From: Simon Perreault <[email-masked]>
Date: Wed, 07 Apr 2010 10:16:44 -0400

> Could you kindly give us some suggestions to make the presentation clearer?

First, I would drop the idea of a "configuration function". This is not 
part of the protocol, it is part of the implementation, and therefore is 
out of scope for this document.

Second, I would pick one alternative and make it a SHOULD. Do you think 
we should floor the MTU to 1280 nor not? Pick one to give guidance to 
the implementors.

Third, make the reference more specific. Section 4 is vast. Is there a 
sub-section that would be more appropriate?

Thanks,
Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 08 Apr 2010 09:41:47 +1200

Simon,

> out of scope for this document.

Actually it is not unusual for a protocol spec to include a statement like
"An implementation of this protocol MUST provide a method to configure
<foobar>, and the default setting of <foobar> SHOULD be <barfoo>."

I think it's a good idea to include such rules.

> we should floor the MTU to 1280 nor not? Pick one to give guidance to

Agreed, there should be a clear default behaviour.

   Brian

---

From: Xing Li <[email-masked]>
Date: Thu, 08 Apr 2010 16:51:38 +0800

> Agreed, there should be a clear default behaviour.

Thanks. We will incorporate your comments in the next update.

regards,

xing, congxiao

---

From: "David Harrington" <[email-masked]>
Date: Fri, 9 Apr 2010 08:56:08 -0400

+1

dbh 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Wednesday, April 07, 2010 5:42 PM
> To: Simon Perreault
> Cc: [email-masked]; Xing Li
> Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-17.txt
> 
> Simon,
> 
> >> Could you kindly give us some suggestions to make the
presentation
> >> clearer?

---

From: Xing Li <[email-masked]>
Date: Sun, 11 Apr 2010 10:54:35 +0800

> dbh 

Thanks for the comments and suggestions. We have uploaded version 18 to 
improve the document.

Regards,

xing, congxiao

>>> First, I would drop the idea of a "configuration function". 
>>>       
>> This is not
>>     
>>> part of the protocol, it is part of the implementation, and 
>>>       
>> therefore is
>>     
>> "An implementation of this protocol MUST provide a method to
>>     
> configure
>   
>>> Second, I would pick one alternative and make it a SHOULD. 
>>>       
>> Do you think
>>     
>>> we should floor the MTU to 1280 nor not? Pick one to give 
>>>       
>> guidance to
>>     
>>> the implementors.
>>>       
>>> Third, make the reference more specific. Section 4 is vast. 
>>>       
>> Is there a
>>

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Wed, 14 Apr 2010 15:51:00 -0700

IPv6 packets can have a valid next header value of No next header (value
55). According to the xlate draft if we simply copy over the next header
value to the protocol of IPv4 then that would be interpreted incorrectly
by the IPv4 side. 

Protocol:  For ICMPv6 (58) changed to ICMPv4 (1), otherwise skip
extension headers, copy the Next Header field (ESP, transport protocol
or undefined next header value) in the last known next header. 

I am suggesting that we should drop the packet with a no next header, as
I don't think we can correctly translate it to a protocol value. Maybe
we could use a reserved protocol value not sure what it buys us.

Any suggestions/opinions?

Senthil

---

From: Dave Thaler <[email-masked]>
Date: Thu, 15 Apr 2010 00:05:13 +0000

No Next Header is value 59 (not 55).

Personally I don't see why 59 should be handled any differently from any
other arbitrary value like 200. Putting 59 in an IPv4 header doesn't seem 
harmful to me, if that's what you'd do for protocol 200 with no data
beyond the IP header.

-Dave

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Senthil Sivakumar (ssenthil)
> Sent: Wednesday, April 14, 2010 3:51 PM
> To: [email-masked]
> Subject: [BEHAVE] IPv6 no next header to IPv4
>

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Wed, 14 Apr 2010 17:42:17 -0700

But the draft does suggest to ignore/drop/translate the other IPv6
specific protocol values like
IPv6-Route (43), IPv6-Frag (44) & dst opts (60). 

-----Original Message-----
From: Dave Thaler [mailto:[email-masked]] 
Sent: Wednesday, April 14, 2010 8:05 PM
To: Senthil Sivakumar (ssenthil); [email-masked]
Subject: RE: IPv6 no next header to IPv4

Personally I don't see why 59 should be handled any differently from any
other arbitrary value like 200. Putting 59 in an IPv4 header doesn't
seem harmful to me, if that's what you'd do for protocol 200 with no
data beyond the IP header.

-Dave

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Senthil Sivakumar (ssenthil)
> IPv6 packets can have a valid next header value of No next header 
> (value 55). According to the xlate draft if we simply copy over the 
> next header value to the protocol of IPv4 then that would be 
> interpreted incorrectly by the IPv4 side.
> 

> I am suggesting that we should drop the packet with a no next header, 
> as I don't think we can correctly translate it to a protocol value. 
> Maybe we could use a reserved protocol value not sure what it buys us.
>

---

From: Xing Li <[email-masked]>
Date: Thu, 15 Apr 2010 19:06:52 +0800

> IPv6-Route (43), IPv6-Frag (44) & dst opts (60). 

The current wording in xlate-18 is

4.1. Translating IPv6 Headers into IPv4 Headers
......
Protocol: For ICMPv6 (58) changed to ICMPv4 (1), otherwise skip
extension headers, copy the Next Header field (ESP, transport
protocol or undefined next header value) in the last known next
header.

We think "copy the Next Header field (ESP, transport protocol or 
undefined next header value) in the last known next header" means "59 
will be put in an IPv4 header, which seems not harmful".

Regards,

xing, congxiao

---

From: Dave Thaler <[email-masked]>
Date: Thu, 15 Apr 2010 20:13:57 +0000

But each of those actually require IPv6-specific processing.
No Next Header, on the other hand is quite different in that it
has no IPv6-specific processing rules.

As such, it is not in the same category as the other 3.
There's really nothing you can do in IPv6 with protocol 59 that
you can't do in IPv4 with protocol 59.

> Sent: Wednesday, April 14, 2010 5:42 PM
> To: Dave Thaler; [email-masked]
> Subject: Re: [BEHAVE] IPv6 no next header to IPv4
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Apr 2010 09:56:58 +1200

However, what can be the value of translating a "no next
header" IPv6 packet into an IPv4 packet? The only meaningful
content can be in some extension header or other, which
can't be translated anyway. Would there be any damage if we
just drop such packets?

    Brian

---

From: Simon Perreault <[email-masked]>
Date: Thu, 15 Apr 2010 18:51:47 -0400

> can't be translated anyway. Would there be any damage if we

Well, if two options are equally good (or equally useless in this case),
why not choose the one which requires less code? That is, make no
special case for 59 and translate/forward it as usual.

Simon

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 15 Apr 2010 16:14:27 -0700

> special case for 59 and translate/forward it as usual.

Doing that should help debug the problem; silently dropping
such a packet might make debugging more difficult.  So I prefer
translating an IPv6 packet containing only IPv6-NoNxt.

I suggest rewording xlate-18 from:

OLD:
   The translator does not translate IPv6 routing headers, hop-by-hop
   extension headers, destination options headers, source routing
   headers, or any layer 4 protocol (e.g., TCP header, IPsec
   authentication header (AH) or encapsulating security payload (ESP)
   header).  However, the translator needs to traverse the IPv6 'next
   header' chain and copy the next header value (which contains the
   transport protocol number) in the last known 'next header' to the
   protocol field in the IPv4 header.  This means that the translator
   MUST forward all protocols to avoid black holing.  Some protocols are
   known to fail when translated (e.g., IPsec AH) and will fail at the
   receiver.
NEW:
   Certain IPv6 headers cannot be translated because they have no
   meaning in IPv4.  These headers are skipped over during processing
   and include HOPOPT (0), IPv6-Route (43), IPv6-Opts (60), and
   source-routing (??). For the first 'next header' that does not match 
   one of the values above, its next header value (which contains the
   transport protocol number) is copied to the protocol field in the IPv4
   header.  This means that all transport protocols are translated.
   Some translated protocols will fail at the receiver for various
   reasons:  some are known to fail when translated (e.g., IPsec AH 
   (51)), others are malformed IPv6 packets with a useless IPv4 
   protocol number (e.g., IPv6-NoNxt (59)), and others will fail
   checksum validation if the address translation is not checksum 
   neutral [I-D.ietf-behave-address-format] and the translator does 
   not update the transport protocol's checksum (because the 
   translator doesn't support recalculating the checksum for that 
   transport protocol, e.g., SCTP (132)).

Comments on this rewording?

Questions for the WG:

1.  I don't know the value of 'source routing headers' (and left 
    it as ?? in the proposed NEW text).  I don't see what value
    from http://www.iana.org/assignments/protocol-numbers should
    be used.

2.  Which transport protcols MUST have their checksums recalculated
    by a translator compliant with draft-ietf-behave-v6v4-xlate, if
    the address translation is not checksum neutral?

    Section 3.5 says:

  "If the address translation algorithm is not checksum neutral, the
   recalculation and updating of the transport-layer headers which
   contain pseudo headers (e.g. of TCP, UDP and DCCP) MUST be 
   performed."

    The use of "e.g." means the list is non-normative.

-d

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Thu, 15 Apr 2010 17:37:15 -0700

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Dan Wing (dwing)
Sent: Thursday, April 15, 2010 7:14 PM
To: [email-masked]
Cc: [email-masked];
[email-masked]
Subject: Re: [BEHAVE] IPv6 no next header to IPv4

> > However, what can be the value of translating a "no next header" 
> > IPv6 packet into an IPv4 packet? The only meaningful content can be 
> > in some extension header or other, which can't be translated anyway.

> > Would there be any damage if we just drop such packets?
> 
> Well, if two options are equally good (or equally useless in this 
> case), why not choose the one which requires less code? That is, make 
> no special case for 59 and translate/forward it as usual.

Doing that should help debug the problem; silently dropping such a
packet might make debugging more difficult.  So I prefer translating an
IPv6 packet containing only IPv6-NoNxt.

OLD:
   transport protocol number) is copied to the protocol field in the
IPv4

[Senthil] When you have fragment header as the next header, according to
the
text, one would end up copying the frag header as the protocol, which is
not correct.
You would want to add some wording for frag header as it is not skipped
over but its
contents are transformed into ipv4 frag values. Also, I suggest removing
the "source routing (??) from the text.

Questions for the WG:

[Senthil] The source routing is an IPv4 term for Routing header (0).

    Section 3.5 says:

-d

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 15 Apr 2010 18:00:28 -0700

> From: Senthil Sivakumar (ssenthil) [mailto:[email-masked]] 
> Sent: Thursday, April 15, 2010 5:37 PM
> To: Dan Wing (dwing); [email-masked]
> Subject: RE: [BEHAVE] IPv6 no next header to IPv4
> 
>  
> 
> [mailto:[email-masked]] On Behalf
> Of Dan Wing (dwing)
> contents are transformed into ipv4 frag values.
>
> Also, I suggest removing the "source routing (??) from the text.

Done.

Revised New text:

NEW:
   Certain IPv6 headers cannot be translated because they have no
   meaning in IPv4.  These headers are skipped over during processing
   and include HOPOPT (0), IPv6-Route (43), and IPv6-Opts (60).
   The IPv6-Frag (44) header is handled as discussed below.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   For the first 'next header' that does 
   not match one of the values above, its next header value (which
   contains the transport protocol number) is copied to the protocol
   field in the IPv4 header.  This means that all transport protocols
   are translated.  Some translated protocols will fail at the
   receiver for various reasons:  some are known to fail when
   translated (e.g., IPsec AH (51)), others are malformed IPv6 
   packets with a useless IPv4 protocol number (e.g., IPv6-NoNxt 
   (59)), and others will fail checksum validation if the address 
   translation is not checksum neutral 
   [I-D.ietf-behave-address-format] and the translator does not 
   update the transport protocol's checksum (because the translator 
   doesn't support recalculating the checksum for that transport 
   protocol, e.g., SCTP (132)).

I believe that entire NEW paragraph should be moved from 4.0 (where
the old paragraph is now) to Section 4.1, "Translating IPv6 Headers into IPv4
Headers", and other text discussing IPv6 headers in 4.1 be removed or
collapsed, such as this existing text in xlate-18's Section 4.1:

  "If any of an IPv6 Hop-by-Hop Options header, Destination Options
   header, or Routing header with the Segments Left field equal to zero
   are present in the IPv6 packet, those IPv6 extension headers MUST be
   ignored (i.e., there is no attempt to translate the extension
   headers) and the packet translated normally.  However, the Total
   Length field and the Protocol field are adjusted to "skip" these
   extension headers.

   If a Routing header with a non-zero Segments Left field is present
   then the packet MUST NOT be translated, and an ICMPv6 "parameter
   problem/erroneous header field encountered" (Type 4/Code 0) error
   message, with the Pointer field indicating the first byte of the
   Segments Left field, SHOULD be returned to the sender."

Or is there some valuable stuff in there we want to keep -- such as
perhaps that sentence starting with "However,", and probably we
want to keep that last paragraph ("If a Routing header with a 
non-zero ...")?

> [Senthil] The source routing is an IPv4 term for Routing header (0).

Ok, so it duplicates HOPOPT.  Thanks.

-d

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Fri, 16 Apr 2010 08:16:24 -0500

> However, what can be the value of translating a "no next header" IPv6
packet into an IPv4 packet? > The only meaningful content can be in some
extension header or other, which can't be translated 
> anyway. Would there be any damage if we just drop such packets?

Unless the mere presence of the packet yields information (such as a
protocol keepalive).

- Wes

---

From: Xing Li <[email-masked]>
Date: Sat, 17 Apr 2010 22:05:25 +0800

Hi, Dan and All,

>    The IPv6-Frag (44) header is handled as discussed below.

We have finished a new version of xlate (version 19) based on the 
proposed text.

>    Length field and the Protocol field are adjusted to "skip" these
The total length is calculated according to the payload length and the 
length of the IPv4 header.
>    Segments Left field, SHOULD be returned to the sender."

It seems that we need to keep this one for better trouble shooting.
> want to keep that last paragraph ("If a Routing header with a 
Thanks for the proposed text and comments.

Regards,

xing, congxiao

---

From: "Ramji Vaithianathan (rvaithia)" <[email-masked]>
Date: Sun, 18 Apr 2010 21:33:37 -0700

Hi,

I have few comments on the latest version 19.

Comment 1: There is reference to SCTP in the latest versions:
>  translated (e.g., IPsec AH (51)), others are malformed IPv6 packets
>   with a useless IPv4 protocol number (e.g., IPv6-NoNxt (59)), and
>   others will fail checksum validation if the address translation is
>   not checksum neutral [I-D.ietf-behave-address-format] and the
>   translator does not update the transport protocol's checksum (because
>   the translator doesn't support recalculating the checksum for that

As I understand SCTP does not use pseudo header for Transport Layer Checksum calculation.  So it should not fail due to not recalculating L4 checksum. However DCCP will fail, if the translator does not recalculate the L4 checksum.  Should we change the reference to DCCP instead of SCTP, something like this:

   translator does not update the transport protocol's checksum (because
   the translator doesn't support recalculating the checksum for that
   transport protocol, e.g., DCCP (33)). 

Alternately, the statement can be introduced as part of following - please refer to the next comment.

Comment 2:

Also we have the following description: 

> 4. Translating from IPv6 to IPv4
>
> When an IP/ICMP translator receives an IPv6 datagram addressed to a
>    destination towards the IPv4 domain, it translates the IPv6 header of
>    the received IPv6 packet into an IPv4 header.  The original IPv6
>    header on the packet is removed and replaced by an IPv4 header.
>    Since the ICMPv6 [RFC4443], TCP [RFC0793], UDP [RFC0768] and DCCP
>   [RFC4340] headers contain checksums that cover the IP header, if the
>   address mapping algorithm is not checksum-neutral, the checksum MUST
>   be evaluated before translation and the ICMP and transport-layer
>   headers MUST be updated.

I had discussed this privately with you on this.  Again the wording seems to imply we MUST support DCCP.  We can probably add a line to indicate DCCP transport header translator is not mandatory.

" When an IP/ICMP translator receives an IPv6 datagram addressed to a
   destination towards the IPv4 domain, it translates the IPv6 header of
   the received IPv6 packet into an IPv4 header.  The original IPv6
   header on the packet is removed and replaced by an IPv4 header.
   Since the ICMPv6 [RFC4443], TCP [RFC0793], UDP [RFC0768] and DCCP
  [RFC4340] headers contain checksums that cover the IP header, if the
  address mapping algorithm is not checksum-neutral, the checksum MUST
  be recalculated during translation and the ICMP and transport-layer
  headers MUST be updated. If the translator does not support translation of DCCP 
  protocol, the transport checksum MAY be left unchanged after translation and the 
  L3 header alone translated.  DCCP protocol MAY fail  because the translator
  does not support translating DCCP protocol"

Comment 3:  Similar comment applies to IPv4 to IPv6 translation.  We could add 

3. Translating from IPv4 to IPv6

   When an IP/ICMP translator receives an IPv4 datagram addressed to a
   destination towards the IPv6 domain, it translates the IPv4 header of
   that packet into an IPv6 header.  The original IPv4 header on the
   packet is removed and replaced by an IPv6 header.  Since the ICMPv6
   [RFC4443], TCP [RFC0793], UDP [RFC0768] and DCCP [RFC4340] headers
   contain checksums that cover IP header information, if the address
   mapping algorithm is not checksum-neutral, the checksum MUST be
   evaluated before translation and the ICMPv6 and transport-layer
   headers MUST be updated.  The data portion of the packet is left
   unchanged.  The IP/ICMP translator then forwards the packet based on
   the IPv6 destination address.  If the translator does not support translation 
   of DCCP protocol, the transport checksum MAY be left unchanged after
   translation and the L3 header alone translated.  DCCP protocol MAY fail
   because the translator does not support translating DCCP protocol.

Thanks,

Ramji

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Xing Li
Sent: Saturday, April 17, 2010 7:35 PM
To: Dan Wing (dwing)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [BEHAVE] IPv6 no next header to IPv4

Hi, Dan and All,

>    The IPv6-Frag (44) header is handled as discussed below.

We have finished a new version of xlate (version 19) based on the proposed text.

> the old paragraph is now) to Section 4.1, "Translating IPv6 Headers 
> into IPv4 Headers", and other text discussing IPv6 headers in 4.1 be 
> removed or collapsed, such as this existing text in xlate-18's Section 4.1:
>
The total length is calculated according to the payload length and the length of the IPv4 header.

> perhaps that sentence starting with "However,", and probably we want 
> to keep that last paragraph ("If a Routing header with a non-zero 
> ...")?
>
>   

Regards,

xing, congxiao