Subject: [Gen-art] review of draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-00.txt

From: Francis Dupont <[email-masked]>
Date: Sun, 19 Jun 2011 00:38:33 +0200

I am the assigned Gen-ART reviewer for this draft. For background on 
Gen-ART, please see the FAQ at 
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments 
you may receive.

Document: draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-00.txt
Reviewer: Francis Dupont
Review Date: 20110618
IETF LC End Date: 20110623
IESG Telechat date: unknown

Summary: Not Ready

Major issues: the "DNS resolver" selection problem is not a DNS problem:
 it comes from a common use of the DNS which is not in the DNS model.
 I agree it is a real world problem but its origin IMHO requires more care
 about its explaination.
 I suggest to ask the DNSOP WG about what to do (and to get the correct
 terminology, IMHO resolver -> caching server). BTW DNSSEC could change
 this: it makes views of not local domains more coherent and the different
 kinds of DNSSEC aware resolvers (*not* caching servers) are host software.

Minor issues:
 - I don't understand why the notion (and well known term) of
  ingress filtering is not used...

 - I have a mixed feeling about the whole document: IMHO it is more
  in the scope of the mif WG, and I am not convinced by it at the
  exception of the negative points (i.e., multi-homing in IPv6 still
  doesn't work at it should...). So what is its real goal?

Nits/editorial comments:
 - 1 page 3: missing comma? in
   "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 resulting in
   hosts with more than one active IPv6 addresses."

 - 1 page 3: definced -> defined?

 - 1 page 4: in its standard model, the DNS is location independent so
  any caching servers should return the same thing... (cf major issue)

 - 1 page 4: resolvers -> caching servers

 - 1 page 4: introduce thee uRPF abbrev (or better use 'ingress
  filtering')

 - 3.1 page 6 (comment): the explaination of scenario 2 strongly
  suggests the use of DHCPv6!

 - 3.3 page 8: another place where 'ingress filtering' is better

 - 3.3 page 8 (and further): there are hosts which manages multiple
 default routers (BTW this doesn't solve the problem at all, the
 text is just not accurate as it assumes no such host exists)

 - 3.3 page 9: ie, -> i.e.,

 - 3.3 page 9: policy routing (Cisco term, Juniper has the same thing
  with a different name) allows a router to determine which traffic
  should be sent to which network (i.e., the text is false).

 - 7.2 page 15: coexistence -> co-existence (i.e., I believe the title
  is right)

 - 8 page 16: his -> its (the policy distributor is a device)

Regards

[email-masked]