Hi, This review did not get copied to IESG or IETF lists. David Harrington Director, IETF Transport Area ietfdbh@xxxxxxxxxxx (preferred for ietf) dbharrington@xxxxxxxxxxxxxxxxxx +1 603 828 1401 (cell) -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@xxxxxxxxxxxxxxxxx] Sent: Wednesday, June 22, 2011 6:45 PM To: David Harrington; 'Transport Directorate' Cc: draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat@xxxxxxxxxxxxxx; 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 [ietfdbh@xxxxxxxxxxx] 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 ietfdbh@xxxxxxxxxxx (preferred for ietf) dbharrington@xxxxxxxxxxxxxxxxxx +1 603 828 1401 (cell) _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf