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

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Sep 2011 16:36:15 +1300

A few comments on this version:

Firstly a general remark, which I am trying to phrase neutrally:

Reading through this and the solutions it proposes, it seems
that DHCPv6 would be mandatory for multihomed multi-prefix
hosts. If that is so, we should say so clearly and be done
with it. Otherwise there will be calls for RA-based solutions
for each aspect.

Now some more specific comments:

> 1.  Introduction
> 
>    IPv6 provides enough globally unique addresses to permit every
>    conceivable host on the Internet to be uniquely addressed without the
>    requirement for Network Address Port Translation (NAPT [RFC3022]),
>    offering a renaissance in end-to-end transparent connectivity.
> 
>    Unfortunately, this may not be possible due to the necessity of NAT
>    even in IPv6, because of multihoming.  

This is a bit scary as written. It would be much nicer if it
read:

 Unfortunately, this may not be possible in every case, due to
 the possible necessity of NAT even in IPv6, because of
 multihoming.

Also, can you introduce NPTv6 right here in the text and use
"NPTv6" everywhere that you use "NAT(66)" in the rest of the
document? We don't want people to associate "NAT" and "IPv6".
Then, update the "Terminology" section accordingly.

...
>    A possible consequence of assigning a host
>    multiple identically-scoped addresses is severely impaired IP
>    connectivity.

This seems a bit alarmist. If the host only had one of those
addresses, its connectivity might be impaired too. I would buy
"sub-optimal IP connectivity."

> 3.2.  Multihomed network environment
...
>    Multihomed networks in IPv4 have been commonly implemented through
>    the use of a gateway router with NAPT function (scenario 2 with
>    NAPT).  

To me "commonly" implies that it is the normal case, and I'm not
sure you can justify that. How about "in many cases"?

> 5.1.  Source address selection
...
>    [I-D.ietf-6man-addr-select-considerations] describes the use of the
>    policy table [RFC3484] to resolve this problem, 

Firstly, draft-ietf-6man-addr-select-considerations is expired.
Is it going to be progressed? Secondly, shouldn't we consider
draft-ietf-6man-rfc3484-revise as the basis now?

I'v got a more basic concern about this section: the real
problem is not source address selection, it's address pair
selection. [See the happy-eyeballs discussion.] I think you at
least need to discuss the fact that with present tools, the host
has to select the destination address and the source address
independently (assuming the destination is *also* multihomed),
and that this is a problem that this draft does not attempt
to solve.

> 8.  Security Considerations
...
>       Policy collision can happen.

I can see why you list this as a possible security issue,
but it's more general than that and probably needs its own
subsection in Section 7 (or possibly in 3484-revise).
It's a problem for every policy distribution scenario,
I think, and the usual approach is to define a precedence
rule and a tie-breaker rule.

    Brian