Subject: [v6ops] 2 prefix for 464XLAT was -- Re: I-D Action: draft-ietf-v6ops-464xlat-03.txt

From: Cameron Byrne <[email-masked]>
Date: Tue, 8 May 2012 06:55:55 -0700

Rémi,

If i may summarize your main points below, you want to eliminate the
possibility of using 2 IPv6 prefix.  It is unclear to me, and i don't
want to debate generalities.  Please provide specific advantages for
the WG to consider.

IPv6 was created with the notion that intefaces will have many IPv6
prefixs.  And, the ONLY scenario that will use more than 1 IPv6
prefixes is when DHCP-PD is used in the access network, and therefore
the CLAT will receive 1 prefix from the network, such as a /56 or /60
... (1 for WAN, 1 for CLAT, n for LAN) ...I see no harm -- and
possible simplification and utility in having a dedicated /64 from the
delegated supernet for translation.

As a network operator, if i can uniformly deploy so that a certain set
of prefixes are known to be 464XLAT IPv4 reachable it makes my life
easier when troubleshooting.  Also, some folks believe that avoiding
NAT44 in the CPE will reduce the complexity.  Why do you want to
remove this option?  The NAT4464 option is open in the spec for anyone
who wants to use it. I need to know why you want that to  be only
path.

CB

On Tue, May 8, 2012 at 6:42 AM, Rémi Després <[email-masked]> wrote:
> Cameron,
>
> Please understand that the goal of comments below is to improve your proposal (which AKAIK not so many people have studied in details).
>
> 2012-05-08 14:35, Cameron Byrne:
>
>> Rémi,
>>
>> Thanks for the review
>>
>> On Tue, May 8, 2012 at 3:07 AM, Rémi Després <[email-masked]> wrote:
>>>
>>> Le 2012-05-08 à 03:24, Masanobu Kawashima a écrit :
>>>
>>>>
>>>> Folks,
>>>>
>>>> We have published draft-ietf-v6ops-464xlat-03.
>>>> Can we move forward to WGLC?
>>>
>>> The new draft has none of the following, discussed on the mailing list, and IMHO still worth dealing with before WGLC:
>>> (1) NAT44 should be a MUST in all cases where the CE node acts as a router.
>>> (2) A well-known 464XLAT interface ID should better be used in CLAT addresses. With it, CLATs never need dedicated prefixes (=> only one case in sections 7.2 and 7.5).
>>> (3) A reference to BIH [RFC6535] should be added. AFAIK, it gives a substance to "It is also possible to provide single IPv4/IPv6 translation service, which will be needed in the future case of IPv6-only servers and peers to be reached from legacy IPv4-only hosts.")
>>>
>>
>> I believe the discussion lead to these outcomes:
>>
>> 1.  NAT44 does not add any utility in case where there can be a
>> dedicated transition prefix.  We took Ole's suggestion for resolving
>> this matter by including both methods and leave it to implementation
>> based on the implementer's circumstances. If the implementer chooses
>> to do NAT44 in all cases, so be it.   But we see no harm in providing
>> choice here.
>
>> It does not force any additional complexity.
>
> It permits the CLAT to always have only one IPv6 address.
> This is in my understanding a non negligible simplification, not compensated by any loss of useful function.
>
>
>> 2.  The OUI idea was clever, but as you pointed out earlier today on
>> the original thread, it did not gain much steam beyond the initial
>> conversation.
>
> The reaction I saw was favorable, with an intent to validate it, but no more comment after that.
>
> Besides, a reference to RFC6052 for both the CLAT and the CLAT addresses, CLAT translators need to work with TWO IPv6 prefixes instead of just one (that of the CLAT and that of the PLAT). This is a requirement that AFAIK exists in no existing RFC (=> the solution is more than a BCP).
>
>
>> Using a dedicated prefix is not a bad thing, IPv6
>> addresses are plentiful.  While reserving the OUI seems simple enough,
>> i am concerned about the added confusion this somewhat unconventional
>> method will create.
>
> Getting simplicity by using an available mechanism IMHO the right way to go.
> Reserving an interface IDs is not "unconventional" since RFC5342 section 2.2.2 and http://www.iana.org/assignments/ethernet-numbers have provisions for that. (Which value to choose remains open AFAIAC, but provided one is reserved.)
>
>
>> 3.  A reference to BIH does not seem required.
>
>>  I am not opposed to
>> it,
>
> Good.
> (*) Without it, can you clarify the meaning of "It is also possible to provide single IPv4/IPv6 translation service, which will be needed in the future case of IPv6-only servers and peers to be reached from legacy IPv4-only hosts."?
>
>> but this document is not required to enumerate all possible
>> solutions, it is to describe one solution summarized in the
>> introduction.  We also do not include references to DS-lite ....
>
> Sure, but see (*) above.
>
>
>>> Besides, some detail suggestions:
>>> In Figures:
>>> - Below PLAT, add NAT64 to clarify that PLAT is no more than a new name for a NAT64 of RFC6146.
>>> In 4.1:
>>
>> PLAT is clearly defined in section 3.
>
> Yes, ... as a ordinary NAT64 (very minor point anyway).
>
>>
>>> - Replace "one IPv4 address can support millions of simultaneous translations" by "one IPv4 address can support more simultaneous translations than with stateless solutions".
>>
>> The focus of this sentence is not to compare with stateless solution,
>> the focus of this sentence is on "port overloading".  Most people
>> think of stateful NAT44 allows for 64,000 translation sessions, but we
>> explicitly state that port overloading allows for millions of sessions
>> per 1 IPv4 address.  I believe this is a meaningful point to make in
>> an IPv4 constrained world.
>>
>>> - Replace "stateless address sharing... are simply not IPv4-efficient enough to solve...", by "stateless address sharing... are not IPv4-efficient enough to solve in all cases...".
>>> In 4.3:
>>
>> OK
>>
>>> - Replace "especially cost-effective in wireless 3GPP...", by "especially cost-effective in Pre-Release 9 wireless 3GPP...".
>>> In 6.1:
>>
>> OK
>>
>>> - Replace "the ISP can provide IPv4 service" by "the ISP can provide outgoing IPv4 service".
>>>
>>
>> In section 1 we state:
>>
>> "The 464XLAT IPv4 service is limited to application
>>   that function in a client server model and is not fit for IPv4 peer-
>>   to-peer communication or inbound IPv4 connections."
>
> Right, but repeating one word where it is clarifying shouldn't be a problem (IMHO).
>
>
> RD
>
>
>
>>
>>
>> CB
>>
>>>
>>> Regards,
>>> RD
>>>
>>>
>>>>
>>>> Changes are:
>>>>
>>>> - Section 7.5. IPv6 Prefix Handling
>>>>  - Clarified the language.
>>>>
>>>> - Added new section "7.6. Relationship between CLAT and NAT44"
>>>>
>>>> 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-03.txt
>>>>>      Pages           : 15
>>>>>      Date            : 2012-05-07
>>>>>
>>>>>  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-03.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-03.txt
>>>>>
>>>>> The IETF datatracker page for this Internet-Draft is:
>>>>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat/
>>>>>
>>>>> _______________________________________________
>>>>> v6ops mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>>
>>>> ========================================
>>>> NEC AccessTechnica, Ltd.
>>>> Product Development Department
>>>> Masanobu Kawashima
>>>> [email-masked]
>>>> http://www.necat.co.jp/
>>>> ========================================
>>>>
>>>> _______________________________________________
>>>> v6ops mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>
>

---

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

> want to debate generalities.  Please provide specific advantages for

Only one case is simpler than two cases, with a choice to be made without being led in the choice to be made.

> easier when troubleshooting.

A reserved Interface ID is AFAIK even simpler.

>  Also, some folks believe that avoiding
> NAT44 in the CPE will reduce the complexity.

I doubt that any home-gateway vendor will have products that cannot support NAT44s.

>  Why do you want to
> remove this option?  

Simplicity.

> The NAT4464 option is open in the spec for anyone

Simplicity.

RD

---

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

>> who wants to use it. I need to know why you want that to  be only

ACK.

Does anyone else care to comment on this topic?  The authors are eager
to settle outstanding issues.  This appears to be important to our
respected colleague Rémi.

Is this matter (support or oppose) important to anyone else?

CB

---

From: Ole Trøan <[email-masked]>
Date: Tue, 8 May 2012 18:21:01 +0200

> Is this matter (support or oppose) important to anyone else?

I support the current text.

(I don't see why removing the NAT44 would be simpler, nor do I see why you should create more restrictions on implementation/deployment than you have to.

cheers,
Ole

---

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

Le 2012-05-08 à 18:21, Ole Trøan a écrit :

> (I don't see why removing the NAT44 would be simpler,

The proposal is not for "removing the NAT44". It is to make the NAT44 a MUST when the CNAT node acts as an IPv4 a router.
Reading what is proposed before rejecting it would be appreciated.
RD

> nor do I see why you should create more restrictions on implementation/deployment than you have to.
> 
> cheers,
> Ole

---

From: Ole Trøan <[email-masked]>
Date: Tue, 8 May 2012 19:00:34 +0200

> The proposal is not for "removing the NAT44". It is to make the NAT44 a MUST when the CNAT node acts as an IPv4 a router.

this would still be an implementation choice. why prohibit an implementation to do better, if it has been deployed with enough address space?

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Wed, 9 May 2012 09:18:53 +0200

Le 2012-05-08 à 19:00, Ole Trøan a écrit :

> this would still be an implementation choice.

> why prohibit an implementation to do better,

To avoid additional complexity without operational utility (doesn't do "better" AFAIK)). 

> if it has been deployed with enough address space?

Which address space?
(464XLAT works with NAT64 PLATs, i.e. with no IPv4 address space assigned to CLAT nodes.)

RD

---

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

On Wed, May 9, 2012 at 2:00 AM, Ole Trøan <[email-masked]> wrote:

> > The proposal is not for "removing the NAT44". It is to make the NAT44 a
> MUST when the CNAT node acts as an IPv4 a router.
>
> this would still be an implementation choice. why prohibit an
> implementation to do better, if it has been deployed with enough address
> space?

For what it's worth, +1 to Remi's arguments on simplicity. Increasing the
possible number of modes of operation superlinearly complicates
implementations and exponentially complicates interoperability testing.