Subject: [Softwires] [Fwd: I-D Action:draft-carpenter-softwire-sample-00.txt]

From: Brian E Carpenter <[email-masked]>
Date: Mon, 07 Jun 2010 19:41:57 +1200

Hi,

This is another approach to stateless tunnels across subscriber NATs.
We've posted it in a preliminary form so that people can compare it with
the SAM-based proposal presented in Anaheim and with draft-lee-softwire-6rd-udp.

    Brian + Sheng

-------- Original Message --------
Subject: I-D Action:draft-carpenter-softwire-sample-00.txt
Date: Mon,  7 Jun 2010 00:30:02 -0700 (PDT)
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Legacy NAT Traversal for IPv6: Simple Address Mapping for Premises Legacy Equipment (SAMPLE)
	Author(s)       : B. Carpenter, S. Jiang
	Filename        : draft-carpenter-softwire-sample-00.txt
	Pages           : 9
	Date            : 2010-06-07

IPv6 deployment is delayed by the existence of millions of subscriber
network address translators (NATs) that cannot be upgraded to support
IPv6.  This document specifies a mechanism for traversal of such
NATs.  It is based on an address mapping and on a mechanism whereby
suitably upgraded hosts behind a NAT may obtain IPv6 connectivity via
a stateless server, known as a SAMPLE server, operated by their
Internet Service Provider.  SAMPLE is an alternative to the Teredo
protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-carpenter-softwire-sample-00.txt

---

From: WashamFan <[email-masked]>
Date: Tue, 08 Jun 2010 16:30:44 +0800

Hi,

There are some concerns after I skimmed over the draft.
How many SIMPLE servers should be deployed in a metro
network? If SIMPLE servers are stateless, would anycast
address be used for avalability and load-balancing?
How does the ISP provision the IP address and port of
SIMPLE servers to the hosts behind the IPv4-only CPEs?
If SIMPLE servers are stateless, I assume the multicast
capability would be absent, right?

Thanks,
washam
----- Original Message -----
From: Brian E Carpenter <[email-masked]>
Date: Tuesday, June 8, 2010 0:26 am
Subject: [Softwires] [Fwd: I-D Action:draft-carpenter-softwire-sample-00.txt]
To: [email-masked]

>  	Title           : Legacy NAT Traversal for IPv6: Simple Address 
> Mapping for Premises Legacy Equipment (SAMPLE)
>  _______________________________________________
>  Softwires mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/softwires
>

---

From: "Konrad Rosenbaum" <[email-masked]>
Date: Tue, 8 Jun 2010 13:30:35 +0200 (CEST)

Hi,

> This is another approach to stateless tunnels across subscriber NATs.

There is of course the big question of how to discover a SAMPLE server. I
doubt they would get any use if the user needed to enter anything in
his/her configuration.

Anycast: runs the risk of landing you in the network of the wrong provider.

Guessing: ...usually goes wrong.

Multicast: not supported by many/most CPEs.

DNS based: kinda like Anycast... no matter how much magic you add.

Maybe a centralized registry?

Also I would change the address format:

       0                           64      80     96     112
      +-------------+-------------+-------+------+------+------+
      |          PSAMPLE          | V4ADDR       | PN   |FILL  |
      +-------------+-------------+-------+------+------+------+

This way the host can set a /96 route to take a shortcut to any other
SAMPLE host inside its own network instead of sending the traffic via its
ISP. But it should be mentioned that under no circumstances host are
allowed to shortcut to hosts with a similar prefix shorter than /96 - they
cannot assume a compatible NAT.

Also it would help to establish the exact handshake to arrive at the
host-ID. My guess would be:

Client(C), Server(S)

C->S Router Solicitation with unspecified source, all-routers (ff02::2)
destination

S->C Router Advertisement with fe80::1 source, final host address
(PSAMPLE:0000:V4ADDR:PN) as destination, PSAMPLE/64 as prefix, should be
M=1?

Now the host can set its host ID, randomize FILL and can do the handshake
again if it thinks it is necessary.

Whether the host-ID of the router should be ::1 or derived from an
existing MAC is also debatable.

Also I do not believe that V4ADDR and PN should be obfuscated - it does
not solve any problem (attackers can simply reverse it) and introduces a
few (the address is not easy to spot for support staff and it risks
miscalculation by some implementers).

Question: does it really make sense to set bits 6/7 of the host-ID to 0? I
do not see much sense in serving the blind assumption of MAC-like behavior
on a MAC-less interface. If so: is it safe to assume that no ISP will have
an IPv4 prefix shorter than /8?

    Konrad

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 09 Jun 2010 21:12:36 +1200

Hi Washam,

Thanks for your comments, see in line. These are my comments;
Sheng may want to comment too.

On 2010-06-08 20:30, WashamFan wrote:
> network? 

Well, that (IMHO) would depend entirely on the load so I think
it is an engineering question.  Since /64 prefixes are abundant,
it would be trivial to have as many SAMPLE servers as you
need for the load.

> If SIMPLE servers are stateless, would anycast

Personally, I think that is complication with no value.
If the SIMPLE server is colocated with another single point
of failure such as the first hop router for a large group
of subscribers, I don't see why you would worry about
load balancing and availability.

> SIMPLE servers to the hosts behind the IPv4-only CPEs?

That doesn't change; they are still provisioned for IPv4
exactly as they are today. The IPv4 service is not changed
in any way.

> capability would be absent, right?

As described so far, SIMPLE is just the same as Teredo and
6to4 as far as multicast goes.

Regards,
     Brian

---

From: WashamFan <[email-masked]>
Date: Wed, 09 Jun 2010 17:27:00 +0800

Hi,

If more than one SIMPLE server deployed and anycast addresses
are not used, how do SIMPLE clients discover the suitable
SIMPLE server, i.e., how do SIMPLE clients get the listener
transport address of the suitable SIMPLE server?

THanks,
washam

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 09 Jun 2010 21:27:03 +1200

Hi Konrad,

> doubt they would get any use if the user needed to enter anything in

Well, that depends on the customer, but in general I think it needs to be
a one-click operation. At the moment we say

  "The SAMPLE interface in the host MUST be configured with the IPv4
   address and UDP listener port number of the SAMPLE server."

There are various ways of automating that, so maybe we can defer the
discussion until we know whether the method is useful.

> Anycast: runs the risk of landing you in the network of the wrong provider.

Absolutely; that would recreate some of the pain of 6to4.

> DNS based: kinda like Anycast... no matter how much magic you add.

Yeah, don't really want any .local nonsense.

> Maybe a centralized registry?

Or SLP. Or an IPv4 DHCP option.

> Also I would change the address format:

Well, the draft uses as closely as possible the Teredo format. Also
we need to respect the u/g bit, which in your proposal means stuffing
2 bits into the V4ADDR field (more comments below). I'm not sure this
is worthwhile to avoid hairpinning.

> existing MAC is also debatable.

I think we can learn from Teredo experience on these things.

> miscalculation by some implementers).

I personally agree. I'm not convinced that simple obfuscation of this
kind has any real value.

> on a MAC-less interface. 

That's a bit of a religious debate. Whenever it comes up, I suggest that
it's an issue for the 6MAN WG. Maybe you want to write a draft "U/G bits
considered harmful" or something.

> If so: is it safe to assume that no ISP will have

If nobody has one today, I think that's a pretty safe assumption.

Regards
      Brian

---

From: "Konrad Rosenbaum" <[email-masked]>
Date: Wed, 9 Jun 2010 15:01:44 +0200 (CEST)

On Wed, June 9, 2010 11:27, Brian E Carpenter wrote:
> a one-click operation.

Actually, for Joe-Average-User it should be zero-click. Teredo only gets
used because it is on per default and requires no configuration
whatsoever.

> At the moment we say

>From the users perspective this makes it more complicated than Teredo.
>From an implementers perspective it makes yet another tunnel protocol.

Only from a network and security perspective it has some limited merit,
since it is somewhat simpler than teredo.

> discussion until we know whether the method is useful.

It is in my opinion useful, but only because it is simpler. The real
benefit will only show up once the discovery method is clear.

[cut]
> Or SLP. Or an IPv4 DHCP option.

Neither is very useful, since they are both designed to work on the LAN.
We need a protocol that can easily cross the NAT box without changing it.
So:

* no multicast (SLP)
* no broadcast (DHCPv4)
* no use of private addresses as target IP
* no DNS magic(*)(**)

(*)some NATs drop what they call "unknown query type" packets
(**)some users use alternative DNS servers as forwarders, which means any
heuristic to find out where you are will fail for them

That leaves either a very simple request via TCP or via UDP - maybe as
some kind of directory lookup.

>> Also I would change the address format:
[cut]
> is worthwhile to avoid hairpinning.

I see.

    Konrad

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Jun 2010 19:16:35 +1200

Konrad,

> benefit will only show up once the discovery method is clear.

Maybe, but isn't the first question whether this approach is
preferable to either a full SAM implementation, or to
draft-lee-softwire-6rd-udp? I'm pretty confident a discovery
method can be devised.

Regards
   Brian

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 10 Jun 2010 10:19:47 -0400

I am also confident that the discovery method can be devised. However, I
think the first question to the WG is:

Any interested in defining a stateless tunnel protocol that works behind
legacy NATv4?

The whole idea of defining this protocol is to provide a lightweight
implementation to allow ISP to introduce v6 to their customers w/o upgrading
the network and home gateway.

If the answer is YES. Then we can work on the technology.

Regards,
Yiu

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 10 Jun 2010 13:57:33 -0700

Brian,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Thursday, June 10, 2010 12:17 AM
> To: Konrad Rosenbaum
> Cc: [email-masked]
> Subject: Re: [Softwires] [Fwd: I-DAction:draft-carpenter-softwire-sample-00.txt]
> 
> Konrad,
> 

SAMPLE server discovery seems analogous to ISATAP router
discovery. One method is to resolve a FQDN to get back a
list of IPv4 addresses of SAMPLE servers. The FQDN could
be delivered to the SAMPLE host when it does the initial
download of the SAMPLE tunnel software, then the host can
periodically (re)resolve the FQDN to get a list of IPv4
addresses of nearby SAMPLE servers.

To the draft p.6 comment about keepalive probes, why not
just send periodic RSs to get RAs back the same as is
done for ISATAP?

Fred
[email-masked]

---

From: Rémi Després <[email-masked]>
Date: Thu, 17 Jun 2010 17:55:22 +0200

> Any interested in defining a stateless tunnel protocol that works behind

This should IMHO be very valuable for IPv6 usage to rapidly spread.
Early references include:
- sec 3.1.1 of draft-despres-softwitre-sam-00
- slides on 6rdE presented in Anaheim (www.ietf.org/proceedings/77/slides/v6ops-3)

> the network and home gateway.

Indeed, and more precisely to introduce "native" IPv6.
("Native" addresses start with prefixes belonging to ISPs that assign them. IPv6 connectivity, and QoS, can thus be better guaranteed than with other addresses, those of Teredo in particular.)

> If the answer is YES. Then we can work on the technology.

I plan to have another draft for Maastricht, with some alternative choices to those of Brian and Sheng.

Regards,
RD