Re: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC

[Brian E Carpenter <[e-mail]>]

Hi,

I think this draft still needs a lot of work.

First, quite a bit of rewriting is needed in the Introduction.

>    Multihoming is a blanket term to describe a host or small network
>    that is connected to more than one upstream network.

I suggest a reference to RFC 3582 here, where the IPv6 requirements
are listed.

>    For example, a remote access user may use a VPN to
>    simultaneously connect to a remote network and retain a default route
>    to the Internet for other purposes.

I don't think this is really a red herring. It's a very common scenario
but it does amount to MIF rather than multihoming, since the
VPN usually appears as a virtual interface. The draft should focus
on MH not on MIF, I think.

>    In IPv4 a common solution to the multihoming problem is to employ
>    NAPT...

Probably this should start by saying that RFC 4116 is the most common
method. It should be made clear that avoiding that method, with its
built-in scaling problem, is of equal importance to avoiding NAPT.

There should also be a discussion of NPTv6, which also avoids NAPT and
RFC 4116. Explain why the proposed approach is a better choice than NPT6.

There needs to be a clear statement that the underlying model is
that having multiple PA prefixes for a site is normal. (And once
you say that, you also need to explain why the proposed solution is
better than shim6, or how it will interact with shim6).

> 2.  Terminology
...
>    NAT66 or IPv6 NAT     The terms "NAT66" and "IPv6 NAT" refer to
>                          [I-D.mrw-nat66].

That is plain wrong. Now I don't understand whether you are trying
to avoid NAPT66 (which is evil) or NPT6 (which is much less evil, and
is the actual topic of draft-mrw-nat66). This needs cleaning up
throughout the draft.

> 3.2.  Multihomed network environment
> 
>    In an IPv6 multihomed network, a host is assigned two or more IPv6
>    addresses and DNS resolvers from independent service provider
>    networks. 

Here I have to agree with Randy - this is not *the* model for IPv6 MH,
it is only one model (which you define earlier as MHMP).

And why mention separate DNS resolvers? Since DNS is a single namespace,
you should get the same (multiple) AAAA records from any resolver.
If not, there's a bug in DNS.

>    ...or use a DNS response from an incorrect
>    service provider that may result in impaired IP connectivity.

No, no, no. Not unless you intend to recommend DNS cheating by
CDNs. Making DNS cheating work should never be an IETF goal.

> 4.3.  DNS server selection

I am very worried by this section. I think this draft should focus
on routing issues; just assume that you get back all the AAAA records
for the target in random order, and go from there.

> 5.  Requirements
> 
>    This section describes requirements that any solution multi-address
>    and multi-uplink architectures need to meet.

I'm puzzled by this section.

1. It seems to cover all kinds of solutions and not just the solution
proposed by this document.

2. It should be much earlier in the document, right after the Introduction.

3. It mixes MH and MIF issues.

4. It needs to explain what is added or changed compared to RFC 3582.

> 6.3.  DNS resolver selection

See above. I think this should be out of scope.

> 7.1.  IPv6 NAT

Drop this except for a reference to NPT6.

> 7.2.  Co-exisitence consideration

I think this is no use as it stands because of the last sentence:

>    The implementation of identifying non-MHMP hosts and NAT policy is
>    outside the scope of this document.

I think all you can say is that hosts that don't support MHMP MAY be
supported by NPT6 or shim6, and if they don't have either of those
they will not get the benefit of multihoming. That is today's
situation anyway, so you have done no harm.

> 8.  Security Considerations
> 
>    This document does not define any new mechanisms.  Each solution
>    mechanisms should consider security risks independently.  Security
>    risks that occur as a result of combining solution mechanisms should
>    be considered in another document.

Er, no. Those risks should be analysed right here in this document.

Also, refer to RFC 4218. Which of those threats apply, and are there
any new ones?

    Brian