Subject: Re: I-D Action:draft-troan-multihoming-without-nat66-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Fri, 28 May 2010 04:33:50 +1200

Hi,

Picking 6man as a likely list to discuss this draft...

Three high level comments:

1. When we did the work that led to RFC 3582, a very clear consensus
was that transport-layer session survival was a required feature of
any acceptable multihoming solution. That promptly blew the whole
idea of plain multi-addressing out of the water, which is of course
how we got to shim6. If you follow the history since then, it's
also how we got LISP and a large part of the RRG work, including
the recent RRG Chairs' recommendation of ILNP.

What has changed? Why would breaking transport sessions be acceptable
now? (I realise that NAT66 based multihoming also breaks transport
sessions, so the same question applies there.)

2. Since that time, I haven't encountered any IT managers that have
any idea in their head of deploying multiple IPv6 prefixes in parallel,
even though it's a design feature and as far as I know works pretty
well apart from the issues raised in this draft.

What reason do we have to believe that the multi-addressing model
will become standard practice? Isn't the avoidance of multi-addressing
95% of the attraction of stateless NAT66 to IT managers?

3. That said, the problems that this draft tackles all seem like
good ones to solve. But I think that tying them to NAT66-avoidance
or even to multihoming confuses things - they are just general
issues created by the IPv6 multi-addressing model itself.

Regards
   Brian

On 2010-05-26 01:15, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : IPv6 Multihoming without Network Address Translation
> 	Author(s)       : O. Troan, et al.
> 	Filename        : draft-troan-multihoming-without-nat66-00.txt
> 	Pages           : 1
> 	Date            : 2010-05-25
> 
> 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 IPv6 NAT.  However, NAT
> should be avoided, if at all possible, to permit transparent host-to-
> host connectivity.  In this document, we analyze the use cases of
> multihoming.  We also describe functional requirements 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 .
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-troan-multihoming-without-nat66-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: <[email-masked]>
Date: Fri, 28 May 2010 09:06:00 +0200

Hi Brian,

just a minor remark below.

> ...
> ...

I'm aware of several network access providers that offer different VLANs to their customers for separating e.g. real-time services from standard Internet services and these VLANs are / will be addressed with different IPv6 prefixes. And that leads to a typical multi-homed RG.

My 2 cents
	Olaf