Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03.txt

[Ray Hunter <[e-mail]>]

I support this work.

1. I am no fan of NAT. One valid use of NAT that I have seen is to 
guarantee a symmetrical return route for packets that have been routed 
at a remote site using policy based routing (PBR) e.g. Internet offload 
of "bulk" traffic.  A mechanism for routers to be able communicate their 
PBR policy table rules to the local end node should be successful.

But IMHO draft-ietf-6man-addr-select-opt-01 would not seem to be 
adequate, as it does not contain enough high-level application related 
information like something being "expensive" AFAIK. And that leaves a 
hard problem of how to communicate a soft policy that may not be based 
on hard classifiers like bandwidth, but rather dollar cost per megabyte.

2. "In short, while IPv6 facilitates hosts having more than one address 
in the same address scope, the application of this causes significant 
issues for a host from routing, source address selection and DNS 
resolution perspectives"

I still like the "learn by trying" approach of Happy Eyeballs (mentioned 
this back in April) even though it may produce some (small) additional 
burden on the network. One problem again is that start-up metrics 
related to SYN packet performance may not provide appropriate/sufficient 
information to be able to formulate effective or meaningful policy for 
source address/destination address/path selection.

As an extension to the "learn by trying" approach, is there a case for a 
hop-by-hop header option for end nodes to be able to learn path 
characteristics from routers (during session start up)?

I doubt that core routers will ever want to process or add such a header 
option, but I could imagine that a CPE router or end node could be 
configured to tag packets containing a TCP SYN going out of interface A 
as being "cheap" and interface B as being "high latency" based on a 
locally configured administrative option.

That tag could be reflected at the server end back to the client during 
session start up.

I'm thinking of the good old EIGRP metrics as a simple starting point 
[bandwidth, delay, reliability, load, minimum MTU, hop count]. Vendor 
extensions of the tags should of course be possible.

These tags would then be used by the end node to be able to select the 
correct path to use (per application) from the successfully negotiated 
paths.

3. "a function to control every node centrally.  A site administrator or 
a service provider could determine or could have an effect on the 
behavior at their users' hosts."

The draft seems to assume that routers or network managers are all 
knowing, and end nodes and end users are dumb. In a model based on 
mobile handsets connected to alternative (competing) networks, the user 
probably knows more than the service providers about what policy they 
want: think WiFi v 4G. I'd thus prefer a model that was more 
symmetrical, where policy selection and communication of path/topology 
information were orthogonal.

regards,
RayH

[e-mail] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF.
>
> 	Title           : IPv6 Multihoming without Network Address Translation
> 	Author(s)       : Ole Troan
>                            David Miles
>                            Satoru Matsushima
>                            Tadahisa Okimoto
>                            Dan Wing
> 	Filename        : draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03.txt
> 	Pages           : 24
> 	Date            : 2011-11-14
>
>     Network Address and Port Translation (NAPT) works well for conserving
>     global addresses and addressing multihoming requirements, because an
>     IPv4 NAPT router implements three functions: source address
>     selection, next-hop resolution and optionally DNS resolution.  For
>     IPv6 hosts one approach could be the use of NPTv6.  However, NAT
>     should be avoided, if at all possible, to permit transparent end-to-
>     end connectivity.  In this document, we analyze the use cases of
>     multihoming.  We also describe functional requirements and possible
>     solutions for multihoming without the use of NAT in IPv6 for hosts
>     and small IPv6 networks that would otherwise be unable to meet
>     minimum IPv6 allocation criteria.  We conclude that DHCPv6 based
>     solutions are suitable to solve the multihoming issues, which
>     described in this document.  Nevertheless, we mention that the
>     possible needs for NPTv6 in the transition phase to the fully
>     deployment of the proposed solutions.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03.txt
>
>