Subject: [Softwires] Fwd: New Version Notification for draft-liu-softwire-ce-comm-shared-addr-00.txt

From: Cong Liu <[email-masked]>
Date: Mon, 17 Feb 2014 03:39:30 +0800

Hi all,

We submitted a new draft about an issue on IPv4 communication between two
Softwire CEs with the same IPv4 addr and different port set.
Any comments are appreciate.

Best Wishes,
Cong

---------- Forwarded message ----------
From: <[email-masked]>
Date: 2014-02-15 0:42 GMT+08:00
Subject: New Version Notification for
draft-liu-softwire-ce-comm-shared-addr-00.txt
To: Jianping Wu <[email-masked]>, Cong Liu <[email-masked]>

A new version of I-D, draft-liu-softwire-ce-comm-shared-addr-00.txt
has been successfully submitted by Cong Liu and posted to the
IETF repository.

Name:           draft-liu-softwire-ce-comm-shared-addr
Revision:       00
Title:          Communication between Softwire CEs with shared addresses
Document date:  2014-02-14
Group:          Individual Submission
Pages:          5
URL:
http://www.ietf.org/internet-drafts/draft-liu-softwire-ce-comm-shared-addr-00.txt
Status:
https://datatracker.ietf.org/doc/draft-liu-softwire-ce-comm-shared-addr/
Htmlized:
http://tools.ietf.org/html/draft-liu-softwire-ce-comm-shared-addr-00

Abstract:
   In some Softwire mechanisms, multiple Customer Edge (CE) devices can
   share the same IPv4 address by using different port sets.  This
   document describes a problem of the IPv4 communication between
   Softwire CEs with the same IPv4 address.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Simon Perreault <[email-masked]>
Date: Mon, 17 Feb 2014 12:37:27 -0500

Le 2014-02-16 14:39, Cong Liu a écrit :
> We submitted a new draft about an issue on IPv4 communication between
> two Softwire CEs with the same IPv4 addr and different port set.

Here's the translation of this draft's recommendation into
implementer-speak:

- Do not assign the shared address to any interface.
- Ensure that NAT is applied after routing.

Should work "out of the box" on Linux.

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

---

From: Ole Troan <[email-masked]>
Date: Tue, 18 Feb 2014 10:19:40 +0100

>> Any comments are appreciate.

the MAP draft already has:

   The MAP architecture described here restricts the use of the shared
   IPv4 address to only be used as the global address (outside) of the
   NAPT [RFC2663] running on the CE.  A shared IPv4 address MUST NOT be
   used to identify an interface.  While it is theoretically possible to
   make host stacks and applications port-aware, it would be a drastic
   change to the IP model [RFC6250].

cheers,
Ole

---

From: Cong Liu <[email-masked]>
Date: Wed, 19 Feb 2014 15:44:28 +0800

Hi Simon,

Thanks for your comments. It's a good implementation to the draft.

Another way is to assign the shared address to the interface, and to
perform a port-based routing.
On Linux, netfilter and ip-rule can be used, to route all such packets
using "main" table instead of "local" table.

Best Regards,
Cong

2014-02-18 1:37 GMT+08:00 Simon Perreault <[email-masked]>:

> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>

---

From: Cong Liu <[email-masked]>
Date: Wed, 19 Feb 2014 16:03:46 +0800

Hi Ole,

Thanks for your comments. The paragraph meets the requirement of this draft.

This draft is to provide advices to MAP, lw4o6, and any other potential
mechanisms.
Do you think it would be helpful, or the description in MAP-E draft is
enough?

Best Regards,
Cong

---

From: Simon Perreault <[email-masked]>
Date: Wed, 19 Feb 2014 08:48:03 -0500

> using "main" table instead of "local" table.

I think that would be asking for trouble. What's the point? Does it even
work with packets sourced by the CPE?

Simon