IPv6 Multihoming without Network Address Translation
draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-06

These recommendations from Joe Touch and Rich Woundy would improve the readability of the document:

(From Joe Touch)
"The same situation that depends on NAT technique may be brought to the IPv6 world."
might be better as:
""Some of the same reasons for IPv4 NATs may be applicable to IPv6."

E.g., larger address space isn't a reason, but address hiding, address 
independence, and service isolation may be. It might even be useful to 
include a brief such list.

(From TSVDIR review by Rich Woundy)
> Can you do a tsvdir review of draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat?

Here are my high level comments on this internet draft.

- The document covers host and gateway requirements, but omits any service provider requirements (eg DHCPv6 option support).
- The security considerations are weak (eg "evil policy") and should be more detailed.
- The source address selection drafts are dead or expired, which does not provide confidence that anyone is working on one of the key solutions advocated by this draft.
- Someone should review the entire document for English grammar, especially section 1.

But if these issues were resolved, this would be a good draft that solves important IPv6 deployment issues.

Detailed comments.

Section 1.

>NAT based multihoming is easily deployable and already deployed technique.

"an already deployed technique"

>The same situation that depends on NAT technique may be brought to the IPv6 world.

Maybe should say "The same situations that require the NAT technique to be used in the IPv4 world may be applicable to the IPv6 world?"

> Whenever a host or small network (which does not meet minimum IPv6 allocation criteria) is connected to multiple upstream networks IPv6 address is assigned by each respective service provider...

"an IPv6 address is assigned"

> resulting in hosts with more than one active IPv6 addresses.

"one active IPv6 address"

> As each service provided is allocated...

"service provider"

> So, the goals for IPv6 multihoming definced in [RFC3582] do not exactly match the goals of us.

"defined in" and "match the goals of this document"

> If multiple routers exist on a single link the host must appropriately select next-hop for each connected network.

"must select the appropriate next-hop"

> it is conceivable that the packets that have inappropriate source address...

"have an inappropriate source address"

> A DNS query sent to an arbitrary upstream resolver may result in incorrect or poisoned responses

Add a period to the end of the sentence.

> A possible consequence of assigning a host multiple identical-scoped addresses...

"identically-scoped"

Section 3.3.

> making it essential for the host to correctly resolve these three criteria before sourcing the first packet.

"resolve these three items..."

Section 4.2.

This section is entitled "Policy providing", which feels like a very awkward term. Have you considered "Policy distribution" or something similar?

I think there may be a few missing requirements for "providing mechanisms". For one, administrators of different networks seem to need to control policies (and nodes' behaviors) independently of other administrators. For another, administrators must control only nodes that are part of their own networks.

Section 5.

General comment. This draft puts requirements on the host (O/S), home gateway and ISP. Any one missing piece will break this solution. This all-or-broken approach makes this solution unlikely to be successful for some time because we can't have an incremental approach. That said, if we have all the pieces, this "should" work.

Section 5.1.

> Scenario 1: "Host" needs to support the solution for this problem
> Scenario 2: "Host" needs to support the solution for this problem

Missing periods. Also note that the service providers (ie ISP and enterprise / VPN) must also support this solution (ietf-6man-addr-select-opt).

Section 5.2.

> Scenario 1: "Host" needs to support the solution for this problem
> Scenario 2: "GW rtr" needs to support the solution for this problem
> Scenario 3: "Host" needs to support the solution for this problem

Missing periods. Also note that the service providers (ie ISP and enterprise / VPN) must also support this solution (ietf-mif-dhcpv6-router-option).

Section 5.3.

> [I-D.ietf-mif-dns-server-selection] proposes a solution for DNS server selection policy providing solution with a DHCPv6 option.

Perhaps it would be simpler to say "[I-D.ietf-mif-dns-server-selection] proposes a solution for distributing DNS server selection policy using a DHCPv6 option."

> Scenario 1: "Host" needs to support the solution for this problem
> Scenario 2: "GW rtr" needs to support the solution for this problem
> Scenario 3: "Host" needs to support the solution for this problem

Missing periods. Also note that the service providers (ie ISP and enterprise / VPN) must also support this solution (ietf-mif-dns-server-selection).

Section 6.1.

> the staticness of the assumed target network environment.

"static nature of the assumed target..."

Section 6.2.

> The DHCPv6 mechanism does not have these difficulties and has the advantages of its relaying functionality.

"has the advantage..."

> The alternative of a policy-based approach is documented in [I-D.ietf-mif-dns-server-selection],where several pairs of DNS

", where..."

Section 7.2.

> 7.2.  Co-exisitence consideration

"Co-existence"

> An idea to achieve this is that GW-rtr identifies the hosts, and then assigns single prefix to non-MHMP hosts and assigns multiple prefix to MHMP hosts.

"a single prefix" and "multiple prefixes".

> In this case, GW-rtr can perform IPv6 NAT only for the traffic from MHMP hosts if its source address is not appropriate.

The MHMP hosts follow the recommendations of this draft, so they don't need IPv6 NAT by definition. Shouldn't this sentence refer to "traffic from non-MHMP hosts"?

> Another idea is that GW-rtr assigns multiple prefix to the both hosts

"multiple prefixes to both hosts"

> In this case, non-MHMP host can access the service through the NAT box.

"the non-MHMP host"

Section 8.

> A policy receiver may receive an evil policy from a policy distributor.

The wording of the Security Considerations section indicate to me that there was no security review of this document. What makes a policy "evil"? Is it because some third party is pretending to be the administrator in distributing policies (ie you need authentication)? Is it because some third party changed the policies in transit, or the policies were corrupted in transit (ie you need integrity checking)?

The authors should take into consideration these security directorate review comments: <http://www.ietf.org/mail-archive/web/secdir/current/msg02739.html>. 

Incidentally, what happens when there are policy conflicts between independent administrators? Who wins?

> A policy distributor should expect some hosts in his network do not follow the distributed policy.

Maybe be even stronger: "will not follow". How can this situation be detected and remediated?

Section 11.1.

> [I-D.ietf-6man-addr-select-opt]
> Matsumoto, A., Fujisaki, T., and J. Kato, "Distributing
> Address Selection Policy using DHCPv6",
> draft-ietf-6man-addr-select-opt-00 (work in progress),
> December 2010.

This normative reference is 'expired'
(http://datatracker.ietf.org/doc/draft-ietf-6man-addr-select-opt/).

> [I-D.ietf-6man-addr-select-sol]
> Matsumoto, A., Fujisaki, T., and R. Hiromi, "Solution
> approaches for address-selection problems",
> draft-ietf-6man-addr-select-sol-03 (work in progress),
> March 2010.

This normative reference is 'dead' (http://datatracker.ietf.org/doc/draft-ietf-6man-addr-select-sol/).

That tells me that both normative references to the preferred source address selection solution are invalid. So do we have a solution to one of the key issues raised by this internet-draft???

From Dave Harrington:
s/offering a renaissance/, offering a renaissance/
otherwise it appears the "requirement for NAT" offers the renaissance, rather than the "without ... NAT" offering the renaissance. It would be much clearer if this were two sentences. and it could be reworded to be technically much clearer than "renaissance".
I agree that an English speaker should go through this document to clarify the English, which uses a lot of phrases and clauses without neccesarily clarifying them by using appropriate punctuation. The RFC Editor will catch many of them, but many of these small changes might impact the representation of WG consensus, and the only real check that the RFC Editor changes are correct happen in AUTH48 by the same authors who didn't write clear text in the first place, presumably because sections were written by editors for whom English is not their native tongue. 
Acronyms are used without references on first use; for example uRPF
in 3.2, scenario 2,
"This gateway router would receive prefix delegations from each independent service provider network and a different set of DNS resolvers." This sentence construction makes it unclear whether the "different set of DNS resolvers" means a set for each provider, or a customer DNS resolver that resolves for both networks. The following sentence doesn't really clarify the scenario. This would be clearer if the sentence was structured as "This gateway router would receive prefix delegations and a set of DNS resolvers from each independent service provider network." (which I assume is what you mean to say).
It would probabyl be helpful if you actually labeled the DNS provider in the scenario diagram.
in the problem statement, scenario 3 bullet 2. Is this a description of a problem? Am I missing what the problem is when "an approrpiate source address will be selected"?
in 4.1, it took me a while to understand the point you wanted to make. There is discussion of a developer "being tempted to assume". So I expected the requirement to address the temptation issue, and whether the developer's assumptions were right or wrong. I think this requirement would be clearer if you didn't express it as "tempted to assume", but rather that end-to-end transparency is required so developers **do not need to** work with complex mechanisms to work around  e2e impediments, as is common in a NAT'd IPv4 environment.
in 4.2, I think the "make nodes behave differently" is too abstract; I think you need some real examples here.
4.3 seems to light; are there any industry numbers available that could help to quantify the scale?

Please note the secdir review from Hilarie Orman, [1] 
I think the points made there are worth noting in the 
security considerations section. There is text in the
review that could almost be cut and pasted for that.

  [1] http://www.ietf.org/mail-archive/web/secdir/current/msg02739.html