Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-02.txt

From: Rémi Després <[email-masked]>
Date: Tue, 8 May 2012 10:53:20 +0200

Le 2012-04-22 à 02:20, Dan Drown a écrit :

> Quoting Rémi Després <[email-masked]>:
>> Now, avoiding ND proxy on two addresses REMAINS POSSIBLE.
>> - It is sufficient that a CLAT interface ID be reserved by IETF/IANA (an ID that no host may legitimately use).
>> - This can be done, in compliance with RFC 5342, with a modified-EUI-64 ID based on IANA's OUI.
>> - Proposed ID value is 02-00-5E-10--00-00-00-00 (in the available range of www.iana.org/assignments/ethernet-numbers for this).
> ...
>> Would you agree on this?
> 
> This sounds good to me.  Using IANA's EUI-64 ID would avoid conflicts with possible interface IDs on v6 tethering (as long as a unique EUI-64 address is assigned to clat).  Since this is just a config file change, I'll go ahead and use it.

Any feedback?
Thanks,
RD

> Thank you,
> Dan

---

From: Dan Drown <[email-masked]>
Date: Tue, 08 May 2012 09:38:52 -0500

Quoting Rémi Després <[email-masked]>:
>> This sounds good to me.  Using IANA's EUI-64 ID would avoid  
>> conflicts with possible interface IDs on v6 tethering (as long as a  
>> unique EUI-64 address is assigned to clat).  Since this is just a  
>> config file change, I'll go ahead and use it.
>
> Any feedback?

I changed my implementation to use a host id in IANA's EUI-64 range by  
default.

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 8 May 2012 07:47:03 -0700

On Tue, May 8, 2012 at 7:38 AM, Dan Drown <[email-masked]> wrote:
>>> This sounds good to me.  Using IANA's EUI-64 ID would avoid conflicts
>>> with possible interface IDs on v6 tethering (as long as a unique EUI-64
>>> address is assigned to clat).  Since this is just a config file change, I'll
>>> go ahead and use it.
>>
>>
>> Any feedback?
>
>

Can your or Rémi provide required draft text that would need to be
updated to incorporate this change?

CB

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

---

From: Rémi Després <[email-masked]>
Date: Tue, 8 May 2012 17:00:40 +0200

> updated to incorporate this change?

I can propose a number of amendments, in line with my comments, but it should take a few days (now under some pressure for the Softwire version of the 4rd draft).

RD

---

From: Washam Fan <[email-masked]>
Date: Thu, 10 May 2012 13:51:47 +0800

Hi,

In sec 7.4. one sentence says:

   The CLAT SHOULD set itself as the DNS server
   via DHCP or other means and proxy DNS queries for IPv4 and IPv6
   clients.

I just don't get it why proxy IPv6 DNS traffic since there would no
translation applied to IPv6 traffic. Would it be correct to remove the
words 'and IPv6' of the sentence?

in sec 7.7, the below sentence seems redundency to me, since it has
been expressed in sec 7.4:

   The router SHOULD set itself as the DNS server advertised
   via DHCP or other means to the clients so that it may implement the
   DNS proxy function to avoid double translation of DNS request.

Would it be better get the sentence removed.

Thanks,
washam

2012/4/17 Masanobu Kawashima <[email-masked]>:
>
> Folks,
>
> We have published draft-ietf-v6ops-464xlat-02.
>
> Changes are:
>
> - Changed document category from Informational to BCP
>  - A normative language(RFC2119) has reinserted.
>  - We did not see any strong opposition on this list except Remi.
>    As Cameron and Lorenzo said, we should not treat as a use case
>    for BIH. Remi's some concerns were fixed by this version as below.
>    If you have any strong opposition, please indicate it.
>
> - Section 7.1. IPv6 Address Format
>  - Replaced all text with this one sentence "IPv6 address format
>    in 464XLAT is defined in Section 2.2 of [RFC6052]"
>
> - Section 7.2. IPv4/IPv6 address translation chart
>  - Removed all references to /96
>  - Added case of "CLAT with NAT44"
>
> - Section 7.4. DNS Proxy Implementation
>  - Added a reference to RFC5625
>
> - Section 7.5. IPv6 Prefix Handling
>  - Removed all references to /96
>  - Added a reference to RFC3633
>
> All comments are welcome.
>
> Regards,
> Masanobu
>
>
>>
>>A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF.
>>
>>       Title           : 464XLAT: Combination of Stateful and Stateless Translation
>>       Author(s)       : Masataka Mawatari
>>                          Masanobu Kawashima
>>                          Cameron Byrne
>>       Filename        : draft-ietf-v6ops-464xlat-02.txt
>>       Pages           : 15
>>       Date            : 2012-04-16
>>
>>   This document describes an architecture (464XLAT) for providing
>>   limited IPv4 connectivity across an IPv6-only network by combining
>>   existing and well-known stateful protocol translation RFC 6146 in the
>>   core and stateless protocol translation RFC 6145 at the edge. 464XLAT
>>   is a simple and scalable technique to quickly deploy limited IPv4
>>   access service to mobile and wireline IPv6-only edge networks without
>>   encapsulation.
>>
>>
>>A URL for this Internet-Draft is:
>>http://www.ietf.org/internet-drafts/draft-ietf-v6ops-464xlat-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-v6ops-464xlat-02.txt
>>
> ========================================
>  NEC AccessTechnica, Ltd.
>  Product Development Department
>  Masanobu Kawashima
>  [email-masked]
>  http://www.necat.co.jp/
> ========================================
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 14 May 2012 13:34:22 +0900

> words 'and IPv6' of the sentence?

Agreed. On a phone that implements tethering, you might want to do this for
other reasons, but I don't see anything in 464xlat that would require it.

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 14 May 2012 12:42:26 -0700

> other reasons, but I don't see anything in 464xlat that would require it.

Agreed, there is no technical requirement to proxy IPv6 DNS traffic.
But, it is frequently prudent to do this and most Home Gateways and
mobile routers do this for reasons described in  rfc5625

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 15 May 2012 09:27:19 +0900

> mobile routers do this for reasons described in  rfc5625

Ack. Then say SHOULD for IPv4 DNS queries (since things really don't work
without it) and MAY for IPv6.

SHOULD is quite a strong statement. If you put in a SHOULD for proxying
IPv6 DNS requests, then you're saying that "there may exist valid reasons
in particular circumstances to NOT proxy IPv6 DNS requests, but the
full implications should be understood and carefully
weighed before choosing a different course."

I don't see the harm if you don't proxy IPv6 DNS lookups. Saying "most
current implementations seem to do this by default" is not sufficient to
say SHOULD IMO. So you're needlessly restricting implementation.

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 14 May 2012 17:56:08 -0700

Ok. Will make this change.

CB