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

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

On 2011-03-02 10:39, [e-mail] wrote:
> Maybe best example of host multihoming, in MIF/NETEXT/MEXT vocabulary at least, is a mobile device that is attached simultaneously to WLAN (provided by one ISP) and cellular (provided by another ISP). The addresses received from those interfaces are completely different, and so may be the level of Internet connectivity provided by each access. In some cases it may be the same corporation providing both accesses (several cellular ISPs have also WLAN hotspot network), but in many cases they are not.
> 
> That kind of multihoming causes several issues (not limited to Internet Protocol suite), which is why your current smartphone very likely uses only one interface at a time. But it does not have to be that way in the future - and it will definitely not be so. 

Sure. But I think it's very important to separate the issues
that apply to multihoming from the issues that are specific to
multiple interfaces (and both from the issues that are specific
to mobility). If we don't solve these problems separately we will
end up with one big mess.

> These private DNS namespaces may appear on WLAN, e.g. if that is closed corporate WLAN, or cellular as well. Of course if VPNs are thrown into soup, also corporation behind VPN tunnel may employ private namespaces.

Unfortunately this is reality and I'm not suggesting we should
ignore reality.

> MIF WG is not promoting multiple DNS namespaces, but recognizes such exist in real life and that hosts need to cope with that. Coping in form of sending DNS queries to nameservers on all interfaces suboptimal and unwanted approach. Interestingly, it seems that in multihoming cases DNSSEC with host based validation is becoming increasingly important feature to support. Anyhow, before any meaningful address and interface selections can be made, IP addresses are needed. Hence need to have means to select which DNS server to contact in order to get IP address.

Yes, but nevertheless, you will end up with multiple AAAA records if
the remote host itself is multihomed - you can't avoid the address
pair selection problem.

   Brian

> Best regards,
> 
> Teemu
> ________________________________________
> From: ext Brian E Carpenter [[e-mail]]
> Sent: Tuesday, March 01, 2011 11:20 PM
> To: Savolainen Teemu (Nokia-MS/Tampere)
> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC
> 
> 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
>