Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe

Simon Perreault <simon.perreault@viagenie.ca> Sat, 01 December 2012 07:46 UTC

Return-Path: <simon.perreault@viagenie.ca>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A40421F8527 for <softwires@ietfa.amsl.com>; Fri, 30 Nov 2012 23:46:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbAuodLROj1W for <softwires@ietfa.amsl.com>; Fri, 30 Nov 2012 23:46:19 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id E155521F8502 for <softwires@ietf.org>; Fri, 30 Nov 2012 23:46:18 -0800 (PST)
Received: from porto.nomis80.org (85-169-39-219.rev.numericable.fr [85.169.39.219]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0798240384; Sat, 1 Dec 2012 02:46:16 -0500 (EST)
Message-ID: <50B9B5C7.107@viagenie.ca>
Date: Sat, 01 Dec 2012 08:46:15 +0100
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2
MIME-Version: 1.0
To: Ole Trøan <otroan@employees.org>
References: <94C682931C08B048B7A8645303FDC9F36E98AB16AD@PUEXCB1B.nanterre.francetelecom.fr> <50B8ADAD.5010409@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E99E2D6F6@PUEXCB1B.nanterre.francetelecom.fr> <9207CAAE-7907-4103-994C-07961030FAE9@employees.org>
In-Reply-To: <9207CAAE-7907-4103-994C-07961030FAE9@employees.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: "softwires@ietf.org" <softwires@ietf.org>
Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Dec 2012 07:46:20 -0000

Le 2012-11-30 20:36, Ole Trøan a écrit :
>> Med: The rationale we adopted in this draft is as follows:
>>
>> * there are three major flavors: full stateful, full stateless, and binding mode
>> * all these modes can support assigning a full or a shared IPv4 address
>
> now you got me thinking, are these really the right modes from a CPE perspective?
>
> let me try to explain, with my CPE implementor hat on, what "modes" would make sense?
>
> - NAT placement. do I need a NAT on the CPE or not?
>    (no NAT && no IPv4 address == DS-lite)
> - full IPv4 address assigned.
>    I can assign the IPv4 address to the tunnel endpoint interface, and use that address for
>    local applications, and as the outbound address of the NAT
>    (mechanisms: MAP, Public 4over6)
> - IPv4 prefix assigned:
>    I need to disable the CPE NAT, and use the assigned IPv4 prefix as my LAN side DHCPv4 pool
>    (mechanism: MAP)
> - Shared IPv4 address.
>    I must enable a local NAT, I cannot assign the IPv4 address on the "WAN" interface, but only use it
>    for the outbound side of the NAT.

Interesting... But note that even just implementing MAP alone would 
generate three of these "implementation modes". I would still like to 
see this list added to an "implementation considerations" section. Stuff 
like "you can't assign a partial address to a tunnel interface" may not 
be obvious to implementers.

> then there might be a sub-modes for "tunnel endpoint determination" i.e. how to determine an IPv6 tunnel end point address given an IPv4 destination address and port.
> 1) algorithmic (MAP)
> 2) configured (Public 4over6, LW46, DS-lite)
>
> and a sub-mode for IPv4 address configuration:
> 1) As "native IPv4"
>      (Public4over6, LW46)
> 2) Embedded Address
>      (MAP)
> 3) None
>     DS-lite
>
> does this make sense?

Totally appropriate for an "implementation considerations" section IMHO.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca