Subject: TSVDIR review request - draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat

From: "David Harrington" <[email-masked]>
Date: Thu, 23 Jun 2011 08:29:23 -0400

Hi,

This review did not get copied to IESG or IETF lists.

David Harrington
Director, IETF Transport Area
[email-masked] (preferred for ietf)
[email-masked]
+1 603 828 1401 (cell)

-----Original Message-----
From: Woundy, Richard [mailto:[email-masked]] 
Sent: Wednesday, June 22, 2011 6:45 PM
To: David Harrington; 'Transport Directorate'
Cc: [email-masked];
Woundy, Richard
Subject: RE: tsvdir review request -
draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat

> 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???

-- Rich

-----Original Message-----
From: Woundy, Richard 
Sent: Friday, June 17, 2011 12:11 PM
To: David Harrington
Cc: 'Transport Directorate'; Woundy, Richard
Subject: RE: tsvdir review request -
draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat

I will get this review done by close of business Tuesday 6/21.
________________________________________
From: David Harrington [[email-masked]]
Sent: Wednesday, June 15, 2011 2:59 PM
To: Woundy, Richard
Cc: 'Transport Directorate'
Subject: tsvdir review request -
draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat

Hi Rich,

Can you do a tsvdir review of
draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat?
due date is 6/21

Thanks,
David Harrington
Director, IETF Transport Area
[email-masked] (preferred for ietf)
[email-masked]
+1 603 828 1401 (cell)