Subject: draft-ietf-v6ops-nat64-pb-statement-req-00 - are changes in dualstack hosts acceptable or not?

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 25 Jul 2008 17:01:38 +0200

Hi,

both Jari and Dave have expressed during email exchanges that unmodified 
dual stack hosts must work well WITHOUT requiring modifications. In 
particular, they expressed that a dual stack host must be able to 
distinguish between the transalted connectivity and the native 
connectivity allowing them to avoid translated connectivity hence 
avoiding failures in apps that don't work through nats.

However, in the current req doc 
(draft-ietf-v6ops-nat64-pb-statement-req-00) it is stated that:

   R1: Changes in the hosts

   The translation mechanism MUST NOT require changes in the v4-only
   nodes to support the Basic requirements described in this section,
   unless explicitly stated in the particular requirement.  The
   translation mechanism MAY require changes to v6-only nodes.

In the list of basic requirements there is another requirement:

   R3: Interaction with dual-stack hosts

   Translation mechanism MUST allow using native connectivity when it is
   available.  This means that if a v6-only nodes wants to communicate
   with a dual stack, it must use native v6 connectivity and if a v4-
   only nodes wants to communicate with a dual stack, it must use native
   v4 connectivity.(In this case, dual stack means a host with both IPv6
   and IPv4 stacks, wich are both active, i.e. they have v4 and v6
   connectivity).

Now, the nice thing about requirements is that when you read 
them into detail, they can be interpreted in both ways.

So, the question is: is a dual stack host a v6 host (i.e. changes are 
acceptable) or is it
a v4 host (i.e. changes are not acceptable)?

Regards, marcelo

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 25 Jul 2008 19:11:14 +0300

> them into detail, they can be interpreted in both ways.

No. A dual-stack host is NOT a v4-only host. If you read the requirements to 
the letter, nothing excludes changes to dual-stack nodes. But I humbly think 
the real question is not what the current requirements say.

> acceptable) or is it a v4 host (i.e. changes are not acceptable)?

Regardless of the current requirements, I would argue it is not acceptable 
that dual-stack nodes need to be modified, for the exact same reason as it is 
not acceptable that IPv4-only nodes need to be modified: deployment would be 
highly impractical.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 25 Jul 2008 18:20:32 +0200

> not acceptable that IPv4-only nodes need to be modified: deployment would be 

do you think it is acceptable to require some manual configuration in 
them to make them work?

Regards, marcelo

---

From: "[email-masked]" <[email-masked]>
Date: Sat, 26 Jul 2008 10:13:39 +0300

Hi,

I have a general problem here that I do not fully understand: why _a_solution_ should not require changes for IPv6-only or dual-stack host, _if_ that gives better functionality than _a_solution_ that does not require changes? We are not limited to single solution on this problem space, right?

We have number of dual-stack implementations out there for which solutions that do not require changes are very desirable.

We also have a large number of to-be-deployed devices in the pipeline, which still can be modified in any ways seen useful. I argue that this number is far larger than the number of already deployed devices, and that this number of devices should not have suboptimal functionality just because we do not want to touch to already deployed v6-capable hosts.

IPv6 deployment is anyhow just beginning.

Best regards,

	Teemu

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of ext Rémi Denis-Courmont
>Sent: 25 July, 2008 19:11
>To: marcelo bagnulo braun
>Cc: Jari Arkko; Dave Thaler; 'IPv6 Operations'; Brian E Carpenter
>Subject: Re: draft-ietf-v6ops-nat64-pb-statement-req-00 - are 
>changes in dualstack hosts acceptable or not?
>
>them into 
>> detail, they can be interpreted in both ways.
>
>No. A dual-stack host is NOT a v4-only host. If you read the 
>requirements to the letter, nothing excludes changes to 
>dual-stack nodes. But I humbly think the real question is not 
>what the current requirements say.
>
>Regardless of the current requirements, I would argue it is 
>not acceptable that dual-stack nodes need to be modified, for 
>the exact same reason as it is not acceptable that IPv4-only 
>nodes need to be modified: deployment would be highly impractical.
>
>--
>Rémi Denis-Courmont
>http://www.remlab.net/
>
>

---

From: Rémi Després <[email-masked]>
Date: Sat, 26 Jul 2008 11:31:09 +0200

[email-masked]  - Le 7/26/08 9:13 AM :

> We also have a large number of to-be-deployed devices in the
> pipeline, which still can be modified in any ways seen useful. I
> argue that this number is far larger than the number of already
> deployed devices, and that this number of devices should not have
> suboptimal functionality just because we do not want to touch to
> already deployed v6-capable hosts.
> 

Full support.

One more point: these "modifications" must ensure *backward compatibility*.
- This the right way to add fuctionnalities.
- Unmodified" devices continue to operate as before.
- They don't prevent others do take advantage of new capabilities.

When backward compatibility is preserved, I personnally prefer more 
precise words as "complements", or "enhancements", or "extensions", to 
"modifications".

Regards.

Rémi Després

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 27 Jul 2008 04:06:35 +1200

On 2008-07-26 04:20, marcelo bagnulo braun wrote:
>> requirements to the letter, nothing excludes changes to dual-stack
>> nodes. But I humbly think the real question is not what the current
>> requirements say.
>>
>>  
>> Regardless of the current requirements, I would argue it is not
>> acceptable that dual-stack nodes need to be modified, for the exact
>> same reason as it is not acceptable that IPv4-only nodes need to be
>> modified: deployment would be highly impractical.
>>   
> 

I think we need to follow the 'first, do no harm' principle
to get this right in the requirements. In other words, the
situation MUST be no worse for unmodified RFC2460/3484 hosts
than it is today. Of course it may be better - otherwise we
wouldn't be here at all. If that requires configuration, it
seems OK to me. After all, we have to be realistic.

    Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 27 Jul 2008 22:58:30 +0100

> acceptable

Note that these issues aren't necessarily binary.

If a dual stack host is presented with synthetic AAAA records along  
with A records, the host will try to use translated connectivity when  
it could have used native connectivity. The requirements require that  
this is avoided. One way to avoid this is to upgrade hosts so they  
automatically prefer real A records over synthetic AAAA records. This  
is rather inconvenient, bu there are only 10 - 20 operating systems in  
the world. Another way to avoid this situation is to make sure that  
dual stack hosts are never served by a recursive nameserver with DNS64  
functionality. However, there are many thousands of ISPs and hundreds  
of thousands of organizations running significant networks in the  
world, which would all have to do this.

So yes, requiring host modifications is bad, but imposing operational  
restrictions has the potential to be much worse in time and money. On  
the other hand, everyone can change their own network, while few  
people can change their OS.