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

Rémi Després <> Thu, 07 October 2010 13:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F2B9F3A6E44; Thu, 7 Oct 2010 06:11:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.441
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id w2dXVOecm6E6; Thu, 7 Oct 2010 06:11:06 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 36EA73A6F8B; Thu, 7 Oct 2010 06:11:03 -0700 (PDT)
Received: from (localhost []) by (SMTP Server) with ESMTP id B87D67000094; Thu, 7 Oct 2010 15:12:05 +0200 (CEST)
Received: from [] ( []) by (SMTP Server) with ESMTP id AE6107000084; Thu, 7 Oct 2010 15:12:04 +0200 (CEST)
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?= <>
In-Reply-To: <>
Date: Thu, 7 Oct 2010 15:12:04 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Washam Fan <>
X-Mailer: Apple Mail (2.1081)
Cc: Softwires <>,
Subject: Re: [v4tov6transition] comments on draft-despres-softwire-6a44-00
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.

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.

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.

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).


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