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

From: Fred Baker <[email-masked]>
Date: Thu, 24 Feb 2011 06:18:35 -0700

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.

---

From: Randy Bush <[email-masked]>
Date: Mon, 28 Feb 2011 17:01:21 +0900

the intro seems to go out of its way to justify a unnecessary complex
situation which the rest of the document goes on to solve.  i.e.

---

   Whenever a host or small network (which does not meet minimum IPv6
   allocation criteria) is connected to multiple upstream networks IPv6
   addressing is assigned by each respective service provider resulting
   in hosts with more than one active IPv6 address.

i have a router currently multi-homed which takes a /48 from one
provider and announces it to all ipv6 bgp peers.  i have seen something
like this before but just can't seem to remember where.

more interesting and controversial is the trend in rir policy to allow
provider independent allocation of /48s to end sites.

---

   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.

red herring

---

   In IPv4 a common solution to the multihoming problem is to employ
   NAPT on a border router and use private address space for individual
   host addressing.

common?  more like extremely rare and somewhat kinky.

---

   It is our goal to avoid the IPv6 equivalent of NAT.  To reach this
   goal, mechanisms are needed for end-user hosts to have multiple
   address assignments and resolve issues such as which address to use
   for sourcing traffic to which destination

good goal.  but how did we leap to end-user hosts needing muliple global
ip addresses?

and this leads in even more complex needs in the subsequent bullets.
when first we weave ...

---

   In short, while IPv6 facilitates hosts having more than one address
   in the same address scope, the application of this causes significant
   issues for a host from routing, source address selection and DNS
   resolution perspectives.  A possible consequence of assigning a host
   multiple identical-scoped addresses is severely impaired IP
   connectivity.

yep.  so don't do it.

---

the rest of the document is based on the unneeded and complex multi-
address assumptions, and therefore gets more and more complex.

nancy was right.  just say no.

randy

---

From: <[email-masked]>
Date: Mon, 28 Feb 2011 12:08:13 +0000

>    multiple identical-scoped addresses is severely impaired IP

Handsets are increasingly able to technically have multiple radios active at the same time (e.g. WLAN and cellular), in addition to having possibilities for IP tunnels..

In the IETF we should clear out obstacles on the path to advanced multi-homing related to Internet Protocol suite itself. Introduction of IPv6 goes a long way already (no overlapping RFC1918 addresses on multiple interfaces..), but we need more to help hosts do wise interface/address selections (routing).

A very simple use case of handset multi-homing is browsing over WLAN access and speaking with VoIP on LTE. Handset must be able to use WLAN access for default Internet traffic and cellular access for VoIP (and if WLAN disappears, switch all traffic to cellular).

Best regards,

	Teemu

---

From: Randy Bush <[email-masked]>
Date: Mon, 28 Feb 2011 21:36:24 +0900

uh oh!  i think i get it.  this is trying to give a new meaning to the
word 'multi-homing' which has been in wide use for a few decades.  it
means bgp routing with multiple peers (a punny word meaning both any
arbitrary bgp neighbor and alternatively one where you only exchange
your customers' routes).

can we please use a new, or at least different, word here?

randy

---

From: Bob Hinden <[email-masked]>
Date: Mon, 28 Feb 2011 16:14:36 +0200

Randy,

> arbitrary bgp neighbor and alternatively one where you only exchange

I would argue that multi-homing has meant different things to different people for a long time as well.

> can we please use a new, or at least different, word here?

I agree this would be very useful and is long overdue.  The multi-homing scenario you described is very different from the multi-homing scenario Teemu described, and these are different from a single site with two prefixes from two ISP not running BGP, etc., etc.

Bob

---

From: Fred Baker <[email-masked]>
Date: Mon, 28 Feb 2011 08:56:10 -0800

> provider independent allocation of /48s to end sites.

well, yes. And it is the resulting deaggregation in the route table that draft-mrw-nat66 is trying to avoid, while retaining the ability for any end system to send a datagram to any other end system modulo policy issues.

---

From: Randy Bush <[email-masked]>
Date: Tue, 01 Mar 2011 05:03:53 +0900

>> more interesting and controversial is the trend in rir policy to
>> allow provider independent allocation of /48s to end sites.
> well, yes. And it is the resulting deaggregation in the route table
> that draft-mrw-nat66 is trying to avoid, while retaining the ability
> for any end system to send a datagram to any other end system modulo
> policy issues.

understood.  and, as i have to pay for the routers carrying the paths, i
am concerned about the results of the ipv6 marketing efforts of the rir
community.  many of the folk who were usually route-conservative became
ipv6 fanboys and, in a marketing frenzy, forgot their heritage.  i think
it's the rir policy wonk's version of adding complexity lipstick to the
protocol pig.

randy

---

From: Joel Jaeggli <[email-masked]>
Date: Mon, 28 Feb 2011 12:05:31 -0800

> can we please use a new, or at least different, word here?

Theoretically the MIF working-group should be working on that definition
if I correctly understand their charter.

> randy
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: <[email-masked]>
Date: Mon, 28 Feb 2011 20:19:08 +0000

I don't really agree. 

For what I know multihoming is very commonly used to describe a scenario where a host has simultaneously multiple uplink ISP connections active. 

MEXT uses that in this context in RFC6089.

HIP uses that in this context in RFC5021.

MOBIKE uses that in this context in RFC4555.

NETLMM uses that in this context in RFC5213.

And I bet there are quite many other RFCs as well. Hence the train to call it something else went already. 

I don't know BGP very well, but doesn't this "BGP routing with multiple peers" sound like being "multihomed" as well, but there just happens to be BGP being used?

Best regards,

	Teemu

> -----Original Message-----
> From: ext Joel Jaeggli [mailto:[email-masked]]
> Sent: 28. helmikuuta 2011 22:06
> To: Randy Bush
> Cc: Savolainen Teemu (Nokia-MS/Tampere); [email-masked]; v6ops-
> [email-masked]; [email-masked]
> Subject: Re: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC
>

---

From: Randy Bush <[email-masked]>
Date: Tue, 01 Mar 2011 05:20:42 +0900

> if I correctly understand their charter.

and, until then, in a droid-like attack, we compound the confusion.
layer four switching here we come.  multi-attached?

randy

---

From: <[email-masked]>
Date: Mon, 28 Feb 2011 20:28:23 +0000

Wikipedia seems to have something to say this:  http://en.wikipedia.org/wiki/Multihoming , covering both our described cases here.. e.g.
--
There are several ways to multihome, separate from the actual protocols used to do so, amongst which the most important are:

Multiple Interfaces, Single IP address per interface:
The host has multiple interfaces and each interface has one, or more, IP addresses. If one of the links fails, then its IP address becomes unreachable, but the other IP addresses will still work. Hosts that have multiple AAAA or A records enabled can then still be reachable at the penalty of having the client program time out and retry on the broken address. Existing connections can't be taken over by the other interface, as TCP does not support this. To remedy this, one could use SCTP which does allow this situation. However SCTP is not used very much in practice.

Multiple Links, Single IP address (Space):
This is what in general is meant with Multihoming. With the use of a routing protocol, in most cases BGP, the end-site announces this address space to its upstream links. When one of the links fails, the protocol notices this on both sides and traffic is not sent over the failing link any more. Usually this method is used to multihome a site and not for single hosts.
--

Teemu

> From: ext Randy Bush [mailto:[email-masked]]
> Sent: 28. helmikuuta 2011 22:21
> To: Joel Jaeggli

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 01 Mar 2011 09:55:08 +1300

I politely suggest that people re-read RFC 4116 and RFC 3582.

And if you really want to avoid repeating several years of
discussion, see the other RFCs listed at
http://www.ietf.org/wg/concluded/multi6.html
and the WG archive at https://ops.ietf.org/lists/multi6/

Multihoming is generic. BGP-4 based multihoming is one solution.
Multi-address based multihoming is a fundamental design property
of IPv6 (and it does not require multiple interfaces, so
MIF is a somewhat different problem).

Regards
   Brian

---

From: Fred Baker <[email-masked]>
Date: Mon, 28 Feb 2011 13:02:51 -0800

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

         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".

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 01 Mar 2011 10:04:15 +1300

On 2011-02-28 21:01, Randy Bush wrote:
...
> common?  more like extremely rare and somewhat kinky.

Huh? Having a different NAPT at each egress is a common technique
in large entreprise networks, so that each egress is PA-addressed as
far as the ISP is concerned. Then internally the enterprise network
uses whatever prefix it wants, either IANA-allocated or RFC 1918.

Of course, externally visible servers have to be in a DMZ that isn't
NATted, but that is a tiny minority of the hosts in such an enterprise.

The ISPs don't know this is happening, just as my ISP at home doesn't
know that I have a consumer NAT.

NPTv6 does exactly this.

   Brian

---

From: Randy Bush <[email-masked]>
Date: Tue, 01 Mar 2011 06:05:33 +0900

> 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".

i recant

randy

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 01 Mar 2011 10:50:54 +1300

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.

>    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