Subject: Re: [BEHAVE] Are NAT translators routers?

From: Fred Baker <[email-masked]>
Date: Sun, 18 Sep 2011 23:37:13 -0700

On Sep 18, 2011, at 1:46 AM, Libor Polčák wrote:

> Hello,
> 
> I am getting familiar with recent RFCs concerning NAT translators in IPv6 environment. I believe that I have found little inconsistency in RFC 6145 and RFC 6296 wording.
> 
> RFC 6145 reads:
> 
> Section 4.1:
> 
> Hop Limit:  The hop limit is derived from the TTL value in the IPv4 header. Since the translator is a router, as part of forwarding the packet it needs to decrement either the IPv4 TTL (before the translation) or the IPv6 Hop Limit (after the translation).  As part of decrementing the TTL or Hop Limit, the translator (as any router) MUST check for zero and send the ICMPv4 "TTL Exceeded" or ICMPv6 "Hop Limit Exceeded" error.
> 
> Section 5.1:
> 
> Time to Live:  Time to Live is derived from Hop Limit value in IPv6 header. Since the translator is a router, as part of forwarding the packet it needs to decrement either the IPv6 Hop Limit (before the translation) or the IPv4 TTL (after the translation).  As part of decrementing the TTL or Hop Limit the translator (as any router) MUST check for zero and send the ICMPv4 "TTL Exceeded" or ICMPv6 "Hop Limit Exceeded" error.
> 
> On the other hand RFC 6296 does not explicitly says that the translator needs to decrement Hop Limit. What is the desired behaviour of NPTv6 translator?

It is in every sense a router, and obeys the expectations of a router. In addition, it does as the RFC describes. In writing 6296 we didn't see any point in saying most of the things a router does - it already does them.

The same is true of a NAT64 translator, with the exception that it must translate the headers entirely if possible, and do something sensible when it can't. In translating everything entirely, in most cases RFC 6145 makes a reversible translation - a source address that has an IPv6 prefix and an embedded IPv4 address becomes that exact IPv4 address in the source position and in the destination position of the reply. Going through the translator, the destinatoin of the translated packet is precisely the value of that original source address. The Hop Limit/TTL bears special notice because it follows a different rule - the translator being a router, the HL/TTL is decremented, which is not reversible.

> I also want to propose change in wording of the above mentioned snippets of RFC 6145 to accommodate RFC 2119 language.
> 
> Instead of:
> 
> Since the translator is a router, as part of forwarding the packet it needs to decrement either the IPv4 TTL (before the translation) or the IPv6 Hop Limit (after the translation).
> 
> Say:
> 
> Since the translator is a router, as part of forwarding the packet it MUST decrement either the IPv4 TTL (before the translation) or the IPv6 Hop Limit (after the translation).
> 
> And similarly instead of:
> 
> Since the translator is a router, as part of forwarding the packet it needs to decrement either the IPv6 Hop Limit (before the translation) or the IPv4 TTL (after the translation).
> 
> Say:
> 
> Since the translator is a router, as part of forwarding the packet it MUST decrement either the IPv6 Hop Limit (before the translation) or the IPv4 TTL (after the translation).
> 
> The reason is that reading the current wording I am not sure if "needs to" actually means MUST or SHOULD. I could fill errata for the change but I want to discuss the suggestion first.

I have no objection to the erratum. 

I'll note that we came by it honestly. The source text is in RFC 2765:

         Hop Limit:
                 TTL value copied from IPv4 header.  Since the
                 translator is a router, as part of forwarding the
                 packet it needs to decrement either the IPv4 TTL
                 (before the translation) or the IPv6 Hop Limit (after
                 the translation).  As part of decrementing the TTL or
                 Hop Limit the translator (as any router) needs to
                 check for zero and send the ICMPv4 or ICMPv6 "ttl
                 exceeded" error.

         Time to Live:
                 Hop Limit value copied from IPv6 header.  Since the
                 translator is a router, as part of forwarding the
                 packet it needs to decrement either the IPv6 Hop
                 Limit (before the translation) or the IPv4 TTL (after
                 the translation).  As part of decrementing the TTL or
                 Hop Limit the translator (as any router) needs to
                 check for zero and send the ICMPv4 or ICMPv6 "ttl
                 exceeded" error.

---

From: Libor Polčák <[email-masked]>
Date: Sun, 18 Sep 2011 10:46:18 +0200

Hello,

I am getting familiar with recent RFCs concerning NAT translators in 
IPv6 environment. I believe that I have found little inconsistency in 
RFC 6145 and RFC 6296 wording.

RFC 6145 reads:

Section 4.1:

Hop Limit:  The hop limit is derived from the TTL value in the IPv4 
header. Since the translator is a router, as part of forwarding the 
packet it needs to decrement either the IPv4 TTL (before the 
translation) or the IPv6 Hop Limit (after the translation).  As part of 
decrementing the TTL or Hop Limit, the translator (as any router) MUST 
check for zero and send the ICMPv4 "TTL Exceeded" or ICMPv6 "Hop Limit 
Exceeded" error.

Section 5.1:

Time to Live:  Time to Live is derived from Hop Limit value in IPv6 
header. Since the translator is a router, as part of forwarding the 
packet it needs to decrement either the IPv6 Hop Limit (before the 
translation) or the IPv4 TTL (after the translation).  As part of 
decrementing the TTL or Hop Limit the translator (as any router) MUST 
check for zero and send the ICMPv4 "TTL Exceeded" or ICMPv6 "Hop Limit 
Exceeded" error.

On the other hand RFC 6296 does not explicitly says that the translator 
needs to decrement Hop Limit. What is the desired behaviour of NPTv6 
translator?

I also want to propose change in wording of the above mentioned snippets 
of RFC 6145 to accommodate RFC 2119 language.

Instead of:

Since the translator is a router, as part of forwarding the packet it 
needs to decrement either the IPv4 TTL (before the translation) or the 
IPv6 Hop Limit (after the translation).

Say:

Since the translator is a router, as part of forwarding the packet it 
MUST decrement either the IPv4 TTL (before the translation) or the IPv6 
Hop Limit (after the translation).

Since the translator is a router, as part of forwarding the packet it 
needs to decrement either the IPv6 Hop Limit (before the translation) or 
the IPv4 TTL (after the translation).

Say:

Since the translator is a router, as part of forwarding the packet it 
MUST decrement either the IPv6 Hop Limit (before the translation) or the 
IPv4 TTL (after the translation).

The reason is that reading the current wording I am not sure if "needs 
to" actually means MUST or SHOULD. I could fill errata for the change 
but I want to discuss the suggestion first.

Best wishes,

Libor Polčák

---

From: Libor Polčák <[email-masked]>
Date: Mon, 19 Sep 2011 12:45:29 +0200

> The same is true of a NAT64 translator, with the exception that it must translate the headers entirely if possible, and do something sensible when it can't. In translating everything entirely, in m…

Hello Fred,

yes, I agree with you. You have a point, NPTv6 is a L3 device and as 
such has to decrement the TTL. I was probably confused because I am 
preparing a project for students that doesn't have much experience in 
network programming and tried to see the text from their point of view. 
Nevertheless, I agree that RFC 6145 has to mention the decrement since 
it copies the value stored in Hop Limit/TTL field.

Thank you for your time,

Libor Polčák

---

From: Ed Jankiewicz <[email-masked]>
Date: Mon, 19 Sep 2011 15:00:52 -0400

Interesting discussion at this point in time.  When I was involved with 
a translator implementation (IPv4 host to IPv6 network) long ago in a 
galaxy far away, we interpreted our role as "fronting" the host, and 
that host behavior w.r.t. hop count was the right interpretation.

I would tend to agree that a translator "in the network" is at least 
acting like a router, and should observe the router requirements, so the 
normative MUST would be appropriate  I believe our translator was a 
special case, i.e. an edge device, where router requirements would not 
apply.

On 9/19/2011 6:45 AM, Libor Polčák wrote:
> Fred Baker wrote:
>>
>> It is in every sense a router, and obeys the expectations of a 
>> router. In addition, it does as the RFC describes. In writing 6296 we 
>> didn't see any point in saying most of the things a router does - it 
>> already does them.
>>
>> The same is true of a NAT64 translator, with the exception that it 
>> must translate the headers entirely if possible, and do something 
>> sensible when it can't. In translating everything entirely, in most 
>> cases RFC 6145 makes a reversible translation - a source address that 
>> has an IPv6 prefix and an embedded IPv4 address becomes that exact 
>> IPv4 address in the source position and in the destination position 
>> of the reply. Going through the translator, the destinatoin of the 
>> translated packet is precisely the value of that original source 
>> address. The Hop Limit/TTL bears special notice because it follows a 
>> different rule - the translator being a router, the HL/TTL is 
>> decremented, which is not reversible.
>
> Hello Fred,
>
> network programming and tried to see the text from their point of 
> view. Nevertheless, I agree that RFC 6145 has to mention the decrement 
> since it copies the value stored in Hop Limit/TTL field.
>
> Thank you for your time,
>
> Libor Polčák
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

-- 
Edward J Jankiewicz, Senior Technical Advisor
ESG/ISD - Center for Navigation and Survivability Systems
SRI International, Inc.
[email-masked]
Direct:  443-502-5815
Google Voice:  908-718-1335