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

Washam Fan <washam.fan@gmail.com> Thu, 07 October 2010 11:45 UTC

Return-Path: <washam.fan@gmail.com>
X-Original-To: v4tov6transition@core3.amsl.com
Delivered-To: v4tov6transition@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id E28573A7101; Thu, 7 Oct 2010 04:45:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.406
X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id L5c6kJclHdfw; Thu, 7 Oct 2010 04:45:58 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com []) by core3.amsl.com (Postfix) with ESMTP id B78B43A70FE; Thu, 7 Oct 2010 04:45:57 -0700 (PDT)
Received: by wyi11 with SMTP id 11so741531wyi.31 for <multiple recipients>; Thu, 07 Oct 2010 04:46:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=OetaB2bTcN56olt5BmyPukHEH/zxXhF2Se1f5w6VGmM=; b=Yd8E1g5uLTO7pZ6VJSFtYeA4UWviiAkZw2SWisPXthmh1cO4/ziQo1WQvDAbwBShkV 3ZFstcqtisETpCHWFKVcjzywesiZ7dDwn4jqM0DNiJZdevBfkrtJyEPfrr5aT2Ay6Pyf 2sWRwsZtJ7aMmsGgY+qBu5VOCygXsxbjdTy/E=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=dZO3LE67ZcEto3jQgty/D8Il9xxkHYT2l+kBZlNLwUfpTp/ArsBKl8BSxNMDa0ZxZ8 1dkEa0cVXwmFd2sizTur/0K69hk4ppBbtd4bdJ3LRKynEdwiXLEKAliq8VrzIKvHNQeo gBFGMPWywBUqnNBzAjkf0UFhQvCd/xgeouDPc=
MIME-Version: 1.0
Received: by with SMTP id l16mr725546wbv.45.1286452019435; Thu, 07 Oct 2010 04:46:59 -0700 (PDT)
Received: by with HTTP; Thu, 7 Oct 2010 04:46:59 -0700 (PDT)
Date: Thu, 7 Oct 2010 19:46:59 +0800
Message-ID: <AANLkTikjtEi=nrO56Op9_JvTRuaxBsry_kVrXTmOh-KJ@mail.gmail.com>
From: Washam Fan <washam.fan@gmail.com>
To: =?ISO-8859-1?B?UultaSBEZXNwculz?= <remi.despres@free.fr>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Softwires <softwires@ietf.org>, v4tov6transition@ietf.org
Subject: [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 11:45:59 -0000


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.

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

3. There is no text in the draft regarding to 6a44 server address
provisioning. 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.

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

I assume the must appearing in the first bullet would have been MUST.
I don't know the second bullet is MUST/SHOULD/MAY or anything else.
Personally, MUST might be too restrictive for the second bullet.

(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;-)