Re: [v4tov6transition] [Softwires] ISP support of Native IPv6 across NAT44 CPEs -Proposed 6a44 Specification

Rémi Després <> Fri, 08 October 2010 09:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 714513A6870; Fri, 8 Oct 2010 02:25:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.458
X-Spam-Status: No, score=-1.458 tagged_above=-999 required=5 tests=[AWL=0.491, 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 Dgjpf7iOVYgg; Fri, 8 Oct 2010 02:25:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E5EB53A684D; Fri, 8 Oct 2010 02:25:47 -0700 (PDT)
Received: from (localhost []) by (SMTP Server) with ESMTP id 164427000090; Fri, 8 Oct 2010 11:26:52 +0200 (CEST)
Received: from [] ( []) by (SMTP Server) with ESMTP id DEB437000091; Fri, 8 Oct 2010 11:26:48 +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: Fri, 8 Oct 2010 11:26:48 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
To: Ole Troan <>
X-Mailer: Apple Mail (2.1081)
Cc: Softwires <>,
Subject: Re: [v4tov6transition] [Softwires] ISP support of Native IPv6 across NAT44 CPEs -Proposed 6a44 Specification
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 08 Oct 2010 09:25:49 -0000

Hi Ole,

As you will see below, you helped to find a bug in the draft!
Many thanks for that.
I hope that after its correction you may become more positive about 6a44. 

Le 8 oct. 2010 à 10:08, Ole Troan a écrit :

> Remi,
>>> ...
>>> issues I have with host tunneling:
>>> - how to communicate with native IPv6 nodes on the same network?
>> The 6a44-S decapsulates IPv6 packets coming from a 6a44 host and, if not destined to another 6a44 host of its network, forwards them in IPv6, in this case on the same network.
> I was thinking of another native IPv6 node in the same home. as 6a44 doesn't enable IPv6 support in the home network I don't see how this would work.

The draft says "In a host, the 6a44 Client function is activated only if the host has an IPv4 address and doesn't have, by any other means, a global unicast IPv6 address".
If there is native IPv6 in a site, 6a44 doesn't apply.

>>> - how to communicate to another 6a44 host on a different link in the same home?
>> 6a44 is only for hosts on a LAN behind a NAT44 attached to a 6a44-capable ISP network.
>> If the LAN has several bridged links, it does apply.
>> Links that are behind extra NATs in the site are out of scope.
>> As I said to Olivier Vautrin in a previous mail on this thread, these extra NATs should be configured so that hosts behind them never receive 6a44 IPv6-Address-Indication messages. (e;g. with the 6a44 well-known port bound to an unassigned internal address.
>> This point isn't in the draft yet but, if co-authors agree, should be in the next version.
> I was thinking of the case of a routed home. no additional NATS. I don't see how the mechanism would work across routers. since you don't get a prefix for the site.

OOPS, Figure 3, where detailed mappings and encapsulations of the intra-site case is bugged (sorry for that).
Hosts A and A2 should have different tunnel ports, i.e. Z and Z2 instead of the same Z:
(v6,<D.N.Z.A>,<D.N.Z2.A2>, data)
        | (v4,A,A2,(UDP,W,W,(v6,<D.N.Z.A>,<D.N.Z2.A2>, data)))
        |                  |
   +----|--+--------+      |             HOST TO HOST
   |    |  |        |      |
   |  -->--+ 6a44-C +------>------
   |  IPv6 |        |<A   IPv4

To be consistent, the host to BR case must only be concerned the destination being different from D.N (not D.N.Z).
It becomes:
(v6,<D.N.Z.A>,<not D.N...>, data)
         | (v4,A,B,(UDP,W,W,(v6,<D.N.Z.A>,not<D.N...>, data)))
         |                  |
    +----|--+--------+      |       HOST TO BORDER ROUTER
    |    |  |        |      |
    |  -->--+ 6a44-C +------>------
    |  IPv6 |        |<A   IPv4

With these behaviors, direct host-to-host communication even if there are routers between them (provided there are no NATs.
This should be clarified in a next version of the draft. (In Figure 1, LAN should be replaced by NAT-less private-IPv4 network.)

> the homegate/homenet WG proposal was rejected by the IESG, but it would have been useful to have the home network architecture document as background for this discussion... 

>>> - do you need non-congruent topology multi-homing policy?
>>> how do you distribute that policy when you don't have a on-link router?
>> Not sure to understand the question.
>> The answer should be NO: 6a44 only needs classical topologies.
> if a 6a44 node is multi-homed to 3 networks, the 6a44 network the IPV4 network and possibly a native IPv6 network (e.g. ULA in the home), would you need to distribute SAS/NH/DNS policy?

See above: 6a44 only applies in a host if there isn't any other IPv6 address.

>>> - a general unease that now every host is supposed to have a "VPN" connection?
>>> how do I configure my own firewall and other network border policy?
>> If the NAT binds the 6a44 well-known port to an unassigned internal address, no host will be able to receive a 6a44 IPv6 address. 
>> Besides, a firewall could filter all packets having this port, source or destination.
> that doesn't give me ability to filter on IPv6 applications on the network border... not specific to 6a44, this is just an artifact of host tunneling.

If no 6a44 packet traverses the FW, there seems to be no need to look at what what they might contain at higher layers.
Did I miss something?

>>> how much would a new CPE cost the customer? 80USD? that's only 5 pints of beer (if bought in Norway.)
>>> I really liked the dongle idea by the way. perhaps with a L2TP LAC.
>> The dongle idea of 6rd-UDP, if without a stateful NAT66 in the dongle, needs an assigned /16 to the function. (The /64 subnet prefix has to contain the site IPv4 address plus the port of the tunnel).
>> This is in general not realistic.
> my suggestion is to use L2TP, which has none of those particular shortcomings.

6a44 doesn't prevent anyone to do something else.
In my understanding, L2TP doesn't keep within a site traffic between two hosts of the site (and is much more complex). 

>> Now, if there is a NAT66 in the dongle, it can work with a 6a44 external address.
>> I hope it helps to understand that 6a44 isn't just one more design for the pleasure to make one, but a pragmatic solution to a real problem, specified after an in depth study. 
> is the in-depth study available?

Just its conclusion, in the draft itself.
I meant a "long and hard" study to get things operational and simple at the end.

Remember that it took me also a long and hard study to finally invent 6rd but that, once it was done, it only took half an hour of verbal explanation to Rani Assaf of to understand the solution, and decide to implement it. (He didn't need a study document.) 

Of course 6a44 isn't quite as simple as 6rd, but I the draft is all I personally need to keep about the solution. Everything else is noise and history.


> cheers,
> Ole