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

From: "t.petch" <[email-masked]>
Date: Tue, 1 Mar 2011 12:09:39 +0100

----- Original Message -----
From: "Fred Baker" <[email-masked]>
To: "savolainen teemu" <[email-masked]>; "Randy Bush"
<[email-masked]>
Sent: Monday, February 28, 2011 10:02 PM

> On Feb 28, 2011, at 12:19 PM, <[email-masked]> wrote:
>
> > For what I know multihoming is very commonly used to describe a scenario
where a host has simultaneously multiple uplink ISP connections active.
>
> There are 185 RFCs and I-don't-know-how-many Internet Drafts (that may or may
not ever become RFCs) that discuss multihoming. And five IENs.
>
> The oldest use of the term I could find is in IEN 110, dated 1979. It uses the
term without definition (it must have been in the air at the time), but states
that
>
>    3.  Hosts which are deliberately multihomed on distinct networks
>    should be able to recover from interface failures, but by mechanisms
>    above the TCP/internet layer, not within them.
>
> So, clearly the expectation there was that "multihomed" implied "[multiple]
distinct networks" and the ability for a host to recover from failures.
>
> IEN 178 has a section with that title. It's introductory comment is that
>
>              A subscriber  may want to have multiple  connections to a
>         communication  system  for reliability or performance reasons.
>
> It goes on to describe having multiple addresses, the ability to use any of
them, and the ability to optimize its use of them, among other things.
>
> The first definition I find that can be described as a "definition" is in RFC
1122; RFC 1123 continues the discussion.

Fred

Prior to RFC1122, I find a definition of multi-homing in RFC791, which is what I
usually use as a reference.

Tom Petch

>          A host is generally said to be multihomed if it has more than
>          one interface to the same or to different networks.  See
>          Section 1.1.3 on "Terminology".
>
> And by the way has a second 3.3.4 on "local multihoming". Since RFC 1122 is
"host" requirements, it doesn't discuss the multihoming of a network. What it
addresses (no pun intended) is a host that is part of two or more subnets,
whether that means two or more interfaces or one interface with multiple
subnets.
>
> RFC 1127, which is Bob Braden's "Perspective on the Host Requirements RFCs",
goes on to discuss "AS Multihoming", which he defines as
>
>    multihomed AS: an AS that has more than one connection to other ASs,
>       but refuses to carry transit traffic.
>
>
>
>
> Bringing this back to the draft in question, my understanding is that the
authors are working from the model in which:
>
> a) a residential/SOHO/other-edge-network has multiple upstreams
> b) said network has at least one CPE
> c) the multiple upstreams provide a prefix each
> d) as a result, the residential/SOHO/other-edge-network has multiple prefixes
overlaid in it.
>
> Every host, by RFC 1122's definition, is multihomed (it has more than one
subnet, regardless of physical connectivity), and the network is multihomed (it
has more than one upstream.
>
>
> Did I miss something? Randy's description of multihomed networks he runes is
perfectly accurate. But BGP is not a requirement for multihoming; what is a
requirement is "multiple addresses" or "multiple upstreams".
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: <[email-masked]>
Date: Tue, 1 Mar 2011 13:43:06 +0000

Chairs, Brian,

I thought we agreed there is no *the* model for IPv6 multihoming term, but the term is overloaded with multiple meanings?

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?)?

Best regards,

	Teemu

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of ext
> Brian E Carpenter
> Sent: 28. helmikuuta 2011 23:51
> To: Fred Baker
> Cc: [email-masked]; [email-masked]; 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

---

From: Fred Baker <[email-masked]>
Date: Tue, 1 Mar 2011 08:01:42 -0800

> usually use as a reference.

    Care must be taken in mapping internet addresses to local net
    addresses; a single physical host must be able to act as if it were
    several distinct hosts to the extent of using several distinct
    internet addresses.  Some hosts will also have several physical
    interfaces (multi-homing).

Grep didn't find it because of the dash...

I actually have a problem with that definition, though. Yes, a host can act as if it were multiple; virtual hosts do that. But in MultiTCP and shim6, the host behaves as if it has more than one address, and the address is (correctly) understood to be a determiner of a route. I understand what Jon was getting at, but I think it is too limiting.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 02 Mar 2011 10:20:02 +1300

> 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

---

From: <[email-masked]>
Date: Tue, 1 Mar 2011 21:39:32 +0000

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. 

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.

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.

Best regards,

Teemu
________________________________________
From: ext Brian E Carpenter [[email-masked]]
Sent: Tuesday, March 01, 2011 11:20 PM
To: Savolainen Teemu (Nokia-MS/Tampere)
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 02 Mar 2011 11:08:45 +1300

> 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…

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 pr…

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…

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

---

From: Randy Bush <[email-masked]>
Date: Wed, 02 Mar 2011 12:13:21 +0900

> I actually have a problem with that definition, though. Yes, a host
> can act as if it were multiple; virtual hosts do that. But in MultiTCP
> and shim6, the host behaves as if it has more than one address, and
> the address is (correctly) understood to be a determiner of a route. I
> understand what Jon was getting at, but I think it is too limiting.

a lot of what jon was getting at was too limiting.  some consider that a
feature not a bug.

    It's perfectly appropriate to be upset.  I thought of it in a
    slightly different way--like a space that we were exploring and, in
    the early days, we figured out this consistent path through the
    space: IP, TCP, and so on.  What's been happening over the last few
    years is that the IETF is filling the rest of the space with every
    alternative approach, not necessarily any better.  Every possible
    alternative is now being written down.  And it's not useful.  
    -- Jon Postel (the summer before he died)

randy

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 04 Mar 2011 13:51:25 -0800

Just a reminder this working-group last call ends to the 10th.

joel

On 2/24/11 5:18 AM, Fred Baker wrote:
> This is to initiate a two week working group last call of
> draft-ietf-v6ops-multihoming-without-nat66. Please read it now. If
> you find nits (spelling errors, minor suggested wording changes,
> etc), comment to the authors; if you find greater issues, such as
> disagreeing with a statement or finding additional issues that need
> to be addressed, please post your comments to the list.
> 
> We are looking specifically for comments on the importance of the
> document as well as its content. If you have read the document and
> believe it to be of operational utility, that is also an important
> comment to make. _______________________________________________ 
> v6ops mailing list [email-masked]

---

From: Satoru Matsushima <[email-masked]>
Date: Thu, 10 Mar 2011 19:04:32 +0900

Fred, Joel, Brian, Bob, Randy, Teemu, Tom and all,

Thanks to all of you for your review and useful feedback during the last call.
We're working on the draft to update with the feedback so then we'll post a revised
version.

Best regards,

--
Satoru Matsushima

---

From: Satoru Matsushima <[email-masked]>
Date: Sun, 27 Mar 2011 10:40:56 +0900

All,

The attached draft is our update version with the feedbacks. I had failed to submit update version of our draft when the draft title had to be changed from "nat66" to "ipv6nat" at final cut-off date. So we'll soon submit updated draft after the submission door open, and ask to chair to change the draft title.

Best regards,
--satoru