Resolution of my discuss comments for draft-ietf-v6ops-nap-02.txt

[Jari Arkko <jari.arkko@piuha.net>]

Hi Tony,

I am looking at -03 and the diffs that you sent. The new
version is much better. More discussion of my DISCUSS
issues below:

> tone/language

Much better indeed, but still a few terms that
you probably should remove (search for "marketing").
Maybe also s/mangling/changing/g.

>2.2 has already been reworked.
>  
>
The new text is better, thanks.

>3.4 does not oversell if you understand how MIPv6 really works. 
>  
>
The text in Section 4.4 of -03 is much better. I'm going to suggest
an additional small change, but first I'd like to explain the concern
that I had.

Draft -02 talked about random address assignment and Mobile IPv6.
However, as you probably know the security of Mobile IPv6 relies
on the home agent knowing which mobile node is authorized to
use which home address, and the existence of a pre-configured
security association between the mobile node and the home agent.
Mobile IPv6 as defined in RFC 3775 did not enable random or even
dynamic home address assignment. We are changing that now as
a part of ongoing work in MIP6 WG (currently a draft in AD Review
stage). However, even after this there is an expectation of an
existing security association per mobile node.

The additional text change that I would suggest is:

      The   
      downsides of using the MIPv6 tunneling method is that it makes   
      usage of middleware like a Home Agent (HA) and consumes slightly   
      more bandwidth for the tunnel overhead.

=>

     The downside with a Mobile IPv6 based solution is that it requires
     a home agent in the network, the configuration of a security
     association for each mobile node, and consumes some amount of
     bandwidth for tunnel overhead. A random, dynamic assignment
     of home addresses without manual intervention also requires
     support for IKEv2-based extension to Mobile IPv6
     [I-D.ietf-mip6-ikev2-ipsec].

>4.2 -2 does not oversell IPsec, it simply states the real situation. 
>  
>
I'm not going to hold your document based on the -03 text, but
I would still suggest the following edit:

       While IPsec might be available in IPv4
       implementations and works the same way, deployment in NAT
       environments either breaks the protocol or requires complex
       helper services with limited functionality or efficiency.
=>
       While IPsec is commonly available in IPv4 implementations
       and can support NATs, NAT support has limitations and
       does not work in all situations. In addition, the use of IPsec
       with NATs consumes extra bandwidth for UDP encapsulation
       and keepalive overhead.

>4.3 has additional text, though this is one where the IESG has lost the
>context of this being wrt a nat deployment. 
>  
>
The new text in -03 works for me.

>4.7 the comments here are just wrong because it already did cover the points
>and there was already a forward reference, it just didn't specify 6.4 as the
>section number.
>  
>
Ah, I missed the reference, sorry. Section 6.4 looks reasonable
to me.

The one remaining thing that I would suggest you add here is
a warning about the issues in multihoming and ingress filtering.
If I read Section 4.7, I get the feeling that multiple prefixes and
multiple ISPs works fine today, which may not be exactly correct,
see e.g. draft-huitema-shim6-ingress-filtering. Do not add a lot
of text, just mention that there are issues in some cases in the
multiple-ISP model.

>I did not buy all of Margaret's personal views though clarifications were
>added. 
>I did not expand on renumbering as Thomas requested. It is not clear to me
>what he wants beyond referencing rfc 4192. The second paragraph of 2.5 could
>be expanded, but that is not the focus of the section. The second paragraph
>of 2.7 could be expanded, but would seem to loose context. It sounds like he
>wants a statement like 'renumbering is hard in IPv4' as justification for
>nat.
>  
>
I need to read the thread on the list between you and Margaret and others
to see if we've converged in the WG about this. I will comment Margaret's
and Thomas' issues and their resolution on the list separately.

--Jari