Re: [v4tov6transition] comments on draft-despres-softwire-6a44-00

Rémi Després <remi.despres@free.fr> Thu, 07 October 2010 13:11 UTC

Return-Path: <remi.despres@free.fr>
X-Original-To: v4tov6transition@core3.amsl.com
Delivered-To: v4tov6transition@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2B9F3A6E44; Thu, 7 Oct 2010 06:11:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.441
X-Spam-Level:
X-Spam-Status: No, score=-1.441 tagged_above=-999 required=5 tests=[AWL=0.508, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2dXVOecm6E6; Thu, 7 Oct 2010 06:11:06 -0700 (PDT)
Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.10]) by core3.amsl.com (Postfix) with ESMTP id 36EA73A6F8B; Thu, 7 Oct 2010 06:11:03 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2204.sfr.fr (SMTP Server) with ESMTP id B87D67000094; Thu, 7 Oct 2010 15:12:05 +0200 (CEST)
Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2204.sfr.fr (SMTP Server) with ESMTP id AE6107000084; Thu, 7 Oct 2010 15:12:04 +0200 (CEST)
X-SFR-UUID: 20101007131204714.AE6107000084@msfrf2204.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@free.fr>
In-Reply-To: <AANLkTikjtEi=nrO56Op9_JvTRuaxBsry_kVrXTmOh-KJ@mail.gmail.com>
Date: Thu, 7 Oct 2010 15:12:04 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <4D58885B-117C-4EDA-8B5F-B37A88E5ED32@free.fr>
References: <AANLkTikjtEi=nrO56Op9_JvTRuaxBsry_kVrXTmOh-KJ@mail.gmail.com>
To: Washam Fan <washam.fan@gmail.com>
X-Mailer: Apple Mail (2.1081)
Cc: Softwires <softwires@ietf.org>, v4tov6transition@ietf.org
Subject: Re: [v4tov6transition] comments on draft-despres-softwire-6a44-00
X-BeenThere: v4tov6transition@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <v4tov6transition.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/v4tov6transition>, <mailto:v4tov6transition-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v4tov6transition>
List-Post: <mailto:v4tov6transition@ietf.org>
List-Help: <mailto:v4tov6transition-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v4tov6transition>, <mailto:v4tov6transition-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Oct 2010 13:11:08 -0000

Thanks Washam for your detailed comments.

Personal reaction below.

Le 7 oct. 2010 à 13:46, Washam Fan a écrit :

> Hi,
> 
> Thanks for your work on this issue.
> 
> I have some comments:
> 
> 1. From 6a44 address format, the 6a44 client can only act as a IPv6
> host but not IPv6 node which could attach to a IPv6 LAN. I think this
> is different from draft-lee-softwire-6rd-udp.

Yes.
But 6rd-udp had such limitations on prefix lengths that it would have had to be modified.
Private discussions led to only envisaged it, in practice, with a stateful NAT66 in the 6rd-udp client.
If a NAT66 in a customer site is accepted, 6a44 can be used to provide its external address. 

> 2. For host to host 6a44 communication, I think there is assumption
> that only one-layer NAT deployed between 6a44 hosts and 6a44 servers.

Yes.
There must be only a *LAN* between 6a44 hosts and CPEs (Fig. 1)

> 3. There is no text in the draft regarding to 6a44 server address
> provisioning.

Good point.
The information exists, but only indirectly (which is insufficient).
The IANA section says:
"For 6a44 to be used, both its IPv4 well-known address B and its well-known port W need to be assigned by IANA."

We could for example add in a next version a bullet in section 4 to say:
"B is the well-known IPv4 anycast address of the 6a44 Server function."


> Since 6a44 servers are stateless, could anycast
> addresses be used? If there are some methods for this provisioning,
> 6a44 server would no need to use well-known UDP ports.

B is indeed an anycast address, as shown by:
"The 6a44 server function can be replicated in any number of routers, known as "6a44 Relays."

The added bullet above, which better defines B, would make it clearer.

> 4. The draft presents 2 restrictions applying for 6a44 deployment in
> terms of MTU issue:
> 
>   o  6a44 ISP networks must have internal IPv4 MTUs of at least 1308
>      octets (which is easy to ensure).
> 
>      *  6a44 hosts must limit to 1280 octets IPv6 packets they transmit
>         to destinations that are not neighbors on their own links.
>         This behavior is already the normal one as long as no other
>         IPv6 path MTU has been reliably discovered.
> 
>   o  6a44 Server functions refuse packets received from their IPv6
>      pseudo interfaces if their sizes exceed 1280 octets, with ICMPv6
>      Packet Too Big messages returned to sources as required by
>      [RFC2460].)
> 
> I assume the must appearing in the first bullet would have been MUST.

Yes.
It can be clarified in the next version.

> I don't know the second bullet is MUST/SHOULD/MAY or anything else.
> Personally, MUST might be too restrictive for the second bullet.

This point isn't 100% clear, I agree.
The text can be improved.
(Yet, as long as PMTU discovery isn't considered reliable, the suggested course of action is the only one that preserves connectivity, which IMHO is a MUST.)
 
> (My Provider deploys NATs in the residential area I live, for some
> apartments, there might be another NAT, itcould be easy to see 2-layer
> NATs for me;-)

Your provider is in the second case of Figure 1. 
To support 6a44, it MUST therefore have a 6a44 Server function next to its NAT function, at entrance of each residential area. 
If it can't, 6a44 isn't a solution for its network.

No simple solution seems to exist in this case, if the IPv6 traffic between hosts of an apartment remains within the apartment (which is considered a MUST for a deployment without customers having bad surprises).


Regards,
RD

PS: I added the two co-authors as cc destinations.
  
> 
> Thanks,
> washam