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

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

On 2011-03-02 02:43, [e-mail] wrote:
> Chairs, Brian,
> 
> I thought we agreed there is no *the* model for IPv6 multihoming term, but the term is overloaded with multiple meanings?

Who is "we"? The nearest we have to an IETF consensus is RFC 3582.
But yes, there is no single model and probably never will be.

> Anyhow, many of the topics have been already discussed in MIF, e.g. multiple namespaces of DNS. Should we repeat the discussion here (for v6ops' education?)?

Having multiple interfaces is not the same thing as multihoming. You can have multiple
interfaces that connect you to the same ISP; if you happen to have two simultaneous
addresses from the same ISP, you are not multihomed in any useful way.

I haven't had time to review the MIF documents, but if MIF intends to recommend
splitting the DNS namespace, I think there will be an enormous fight at IETF level.

   Brian

> 
> Best regards,
> 
> 	Teemu
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of ext
>> Brian E Carpenter
>> Sent: 28. helmikuuta 2011 23:51
>> To: Fred Baker
>> Cc: [e-mail]; [e-mail]; Ron Bonica
>> Subject: Re: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC
>>
>> 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
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>