Subject: RE: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00.txt).

From: Khaled Omar <[email-masked]>
Date: Thu, 22 Dec 2016 10:29:15 +0000

Hi All,

Easy next step, some RFCs should be obsoleted and some others should be updated.

For example, these RFCs should be obsoleted:

RFC 1853.
RFC 2766.
RFC 6146.
RFC 6144.
       .
       .

These RFCs should be updated:

RFC 2460.
      .
      .
      .

Looking for a private discussion regarding IPv10 future topics.

Best regards,

Khaled Omar

From: Khaled Omar
Sent: Wednesday, December 21, 2016 10:24 PM
To: [email-masked]'
Subject: IPv10 (Temp. name IPmix) (draft-omar-ipv10-00.txt).

Hi IETF members,

I would like to inform you that the IPv10 Internet draft has been successfully uploaded.

Here is the link for the IPv10 Internet draft https://www.ietf.org/id/draft-omar-ipv10-00.txt

All  participants for the IPv10 discussion regardless if there will be addition or modification will be highly appreciated.

Thanks for your time.

Best Regards,

Khaled Omar

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 22 Dec 2016 12:01:16 +0100

Dear Khaled,

if you are a new implementation of the Turing Test, then pass my deepest compliments to your author. Otherwise, PLEASE STOP sending this to the [email-masked] mailing list.

Thanks, Lada

> On 22 Dec 2016, at 11:29, Khaled Omar <[email-masked]> wrote:
> 
> Hi All,
>  

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Leonir Hoxha <[email-masked]>
Date: Thu, 22 Dec 2016 12:14:15 +0100

Hi Khalid,

Are you aware what you are proposing!!?
Those RFCs are incorporated into all the Vendors for many years now.
Hundreds of Experts have been working on these Protocols, and you just want
them to obsolete?

What is your value proposition, I have read your letter, but honestly it
doesn't give me any feeling that it is a real solution.
We do have IPv6/IPv4 already talking to each other, why do you think an
additional Address Family would make our life easier?

Please consider this, and try to answer these questions to yourself.

And last, please STOP sending mails to [email-masked], this is not the right
way to do it.

Regards,
Leonir Hoxha

On Thu, Dec 22, 2016 at 12:01 PM, Ladislav Lhotka <[email-masked]> wrote:

> Dear Khaled,
>
> if you are a new implementation of the Turing Test, then pass my deepest
> compliments to your author. Otherwise, PLEASE STOP sending this to the
> [email-masked] mailing list.
>
> Thanks, Lada
>
> > Here is the link for the IPv10 Internet draft
> https://www.ietf.org/id/draft-omar-ipv10-00.txt
> >
> > All  participants for the IPv10 discussion regardless if there will be
> addition or modification will be highly appreciated.
> >
> > Thanks for your time.
> >
> > Best Regards,
> >
> > Khaled Omar
>
> --

-- 

----
*Leonir Hoxha*

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 28 Dec 2016 11:22:46 -0800

Leonir Hoxha wrote:

> Hundreds of Experts have been working on these Protocols, and you just
> want them to obsolete? 
>
> And last, please STOP sending mails to [email-masked], this is not the right way to do it.

On the contrary, the calls for someone to stop sending work that is outside the scope of any existing working group to this list are "not the right way to do it". If you believe this belongs in an existing group, redirect as appropriate. If this is truly a new protocol and doesn't fit alongside existing work, it belongs here to help determine consensus about forming a new working group. 

That said, at best this belongs in v6ops as a transition approach. In reality, it is inconsistent with itself to the point where it can't be implemented, even if you wanted to. The section 3 descriptions use variable length headers, while the section 4 description of the proposed "new protocol" header is fixed length. Independent of that, the author has not recognized existing technology (RFC 4921 Sections 2.5.5.1 & 2.5.5.2) that does more than what this draft is proposing despite being pointed at that a month ago. 

Finally, this proposal does nothing to solve the problem it identifies, legacy IPv4 hosts in the enterprise environment that will not migrate. There appears to be an unstated assumption that administrators of legacy hosts will make the changes necessary for this inconsistent and underspecified proposal, despite the demonstrated fact that they are unwilling to make the well documented changes to deploy IPv6 because they simply refuse to make a change, or to  learn something new. 

In the beta version of Windows XP I made sure IPv6 was ON-BY-DEFAULT, with no knob to turn it off, because I knew that given the option enterprise administrators would turn it off. I lost the battle in the shipping version though, and sure enough the first things that showed up on search engines were instructions for how to turn IPv6 off. The lack of deployed end systems limited the willingness of app developers to bother making their changes, which in turn fed the resistance to change by the intermediate network administrators. Fast forward to the point where IPv6 is required, and forcing the changes outward from the middle is proving to be as difficult as predicted. The IPv10 proposal does nothing to solve this fundamental problem, and actually amplifies it by removing what clarity there is in dual-stack network administration and diagnostics.

Tony

---

From: Steve Crocker <[email-masked]>
Date: Wed, 28 Dec 2016 20:12:14 -0500

Tony,

I’ve been trying to understand the dynamics of IPv6 adoption.  Your note fills in part of the puzzle.  Nice!

Thanks!

Steve

> On Dec 28, 2016, at 2:22 PM, Tony Hain <[email-masked]> wrote:
> 
> [Regarding the problem of legacy IPv4 hosts in the enterprise environment that will not migrate, [it has been] demonstrated fact that [administrators of legacy hosts] are unwilling to make the well documented changes to deploy IPv6 because they simply refuse to make a change, or to  learn something new. 
> 
> In the beta version of Windows XP I made sure IPv6 was ON-BY-DEFAULT, with no knob to turn it off, because I knew that given the option enterprise administrators would turn it off. I lost the battle in the shipping version though, and sure enough the first things that showed up on search engines were instructions for how to turn IPv6 off. The lack of deployed end systems limited the willingness of app developers to bother making their changes, which in turn fed the resistance to change by the intermediate network administrators. Fast forward to the point where IPv6 is required, and forcing the changes outward from the middle is proving to be as difficult as predicted.
> 
> Tony

---

From: Randy Bush <[email-masked]>
Date: Thu, 29 Dec 2016 10:47:18 +0900

> Finally, this proposal does nothing to solve the problem it
> identifies, legacy IPv4 hosts in the enterprise environment that will
> not migrate. There appears to be an unstated assumption that
> administrators of legacy hosts will make the changes necessary for
> this inconsistent and underspecified proposal, despite the
> demonstrated fact that they are unwilling to make the well documented
> changes to deploy IPv6 because they simply refuse to make a change, or
> to learn something new.

exactly.  enterprises have een controllong their environments and
permissions across it based on ip assignment via dhcp for a few
decades.  and ipv4 nat is a much easier and cheaper way to get their
job done than trying to deal with ipv6.

in general, i do not find it a very viable business strategy to tell
my customers to do things they just do not want to do.  pushing water
uphill.  and we have been so good at denial for a decades.

we blamed the operators.  we blamed the cpe vendors.  we blamed the
router vendors.  and now we blame the users.  it's always someone
else's fault.

randy

---

From: [email-masked]
Date: Wed, 28 Dec 2016 22:14:34 -0500 (EST)

demonetize IPv4 addresses and the problem will solve itself.  there is 
financial inertia on the side of retaining v4 only stack networks.

---

From: David Conrad <[email-masked]>
Date: Wed, 28 Dec 2016 20:27:13 -0800

On Dec 28, 2016, at 7:14 PM, [email-masked] wrote:
> demonetize IPv4 addresses and the problem will solve itself.

Do you have some magic wand that can make that happen?  It would seem the opposite is happening -- the price for IPv4 addresses is climbing, with rumors of some folks trying to corner the market. This is, of course, unsurprising given Economics 101 and the laws of supply and demand. Should make for interesting times ahead for those organizations that continue to demand IPv4 addresses.

> there is financial inertia on the side of retaining v4 only stack networks.

My suspicion (hope?) is that the increased price of IPv4 (and operational challenges dealing with GGNAT) will encourage folks to take IPv6 more seriously.

Regards,
-drc
(speaking only for myself)

---

From: Randy Bush <[email-masked]>
Date: Thu, 29 Dec 2016 13:37:26 +0900

> Do you have some magic wand that can make that happen?

i thought we were talking enterprise.  cost of space in 10/8 is
halving hourly.

until we provide an easier and cheaper approach than nat, the
enterprises will continue to nat.  instead we tell them that they
are stupid and do not understand the true religion; and when they
finally do, the light of day will shine upon them.  problem is
that folk have been blowing sunshine up their trousers/skirts
since dirt was invented; they just ignore it and do what is best
for their bottom line this quarter.

randy

---

From: [email-masked]
Date: Wed, 28 Dec 2016 23:47:04 -0500 (EST)

>> Do you have some magic wand that can make that happen?

I wish.  Might take a time machine, methinks.

> enterprises will continue to nat.

can we killer app it?  something that end to end connectivity through 
public addressing will allow that NAT is a hassle for?  It seems a 
tremendous amount of work went into various approaches at making SIP work 
across a natted connection.

> instead we tell them that they

---

From: "Patrik Fältström" <[email-masked]>
Date: Thu, 29 Dec 2016 08:17:10 +0100

> My suspicion (hope?) is that the increased price of IPv4 (and operational challenges dealing with GGNAT) will encourage folks to take IPv6 more seriously.

...in combination with the increased a. announcements of unannounced (regardless of whether it is allocated or not) address space; and ultimately b. announcements of address space that is announced (as people will just not care if someone on the other side of the planet use the space or not).

I.e. we can just sit down, do our homework, and people will one day see IPv4 is more work for them than IPv6. And with homework I mean continue to improve management and use of IPv6 address space. There is still so much more to be done. Because one day people will come and ask for it, and when that happens we better have the tools ready.

   paf

---

From: John C Klensin <[email-masked]>
Date: Thu, 29 Dec 2016 04:03:56 -0500

Patrik,

I think that view of the world depends on one critical
assumption, i.e., that the end-to-end model actually has
significant value.  To at least some degree, every installed
carrier-grade NAT, every provider who sees the Internet in
content delivery terms, every country that believes it should
control addressing within its national boundaries, every ISP who
has figured out a way to charge close to an order of magnitude
more for a connection that (legally and technically) allows
server functions rather than only client ones, perhaps every
application or mechanism that assumes the web is the Internet
and nothing else counts, etc., pushes us in the other direction.
Each of those decisions/ actions is motivated, at least in part,
by considerations other than IPv4 address space exhaustion
and/or cost.

There is also a chance that the Davies-Baran packet hypothesis
was incorrect and that, at current and future scale, flows and
dedicated or dynamic virtual circuits, even if packets are run
over them, really are a better way to run at least the core of a
network.  In addition to the more obvious cases, almost every
step toward "we should run communications between you and me
over an encrypted tunnel to protect our privacy" pushes us more
toward call setup and virtual circuits. 

In those directions, overlapping address ranges separated by
ALGs work more than well enough and, from some points of view,
have significant advantages of their own.  If we go there, as
some readings of current behavior suggest we may to be going, we
will wait a really long time before your "one day" gets close.
Indeed, it may be receding at several months per month as we get
better at not deploying IPv6.

I hope I'm wrong, but "we" spent many years trying to tell
people that IPv6 was completely ready, that all transition
issues had been sorted out and the needed mechanisms were
well-understood, and that deployment would be easy and painless.
When those stories became ever more clearly false, "we" then
fell back on claims or threats that failure to deploy IPv6
before assorted events occurred would cause some evil demon to
rise up ad devour them and their networks.  Most of those events
have now occurred without demonstrable bad effects; each one
that does reduces our credibility and the credibility and
plausibility of IPv6.  Perhaps had plans like Tony's prevailed
15+ years ago, we'd be in much better shape, perhaps not, but,
to a considerable extent, each year we live without widespread
IPv6 (and no obvious signs of severe damage as a result) makes
it harder to convince people of the necessity of incurring the
costs and disruption of converting.

The big problem with IPv6 deployment is the same as it was
twenty years ago: most of the incentives we have offered as to
why people should convert are not any obvious and significant
advantages of the new protocol/ address model itself but fear of
Bad Things Happening as IPv4 address space becomes depleted.
Without significant positive incentives, the arguments,
especially the economic ones, for putting resources into
mitigating those threatened Bad Things or their consequences are
as strong or stronger than the arguments for deploying a new
protocol, an action that has many technical and non-technical
costs, especially when no one seems to have a realistic theory
that avoids having to operate IPv4 and IPv6 networks in parallel
for an extended period.

I don't particularly dislike IPv6, I just think we've failed to
pay enough attention to incentives and barriers.  I wish it were
otherwise, really I do.

sadly,
    john

--On Thursday, December 29, 2016 08:17 +0100 Patrik Fältström
<[email-masked]> wrote:

>> My suspicion (hope?) is that the increased price of IPv4 (and
>> operational challenges dealing with GGNAT) will encourage
>> folks to take IPv6 more seriously.
> 
> ...in combination with the increased a. announcements of
> unannounced (regardless of whether it is allocated or not)
> address space; and ultimately b. announcements of address
> space that is announced (as people will just not care if
> someone on the other side of the planet use the space or not).
> 
> I.e. we can just sit down, do our homework, and people will
> one day see IPv4 is more work for them than IPv6. And with
> homework I mean continue to improve management and use of IPv6
> address space. There is still so much more to be done. Because
> one day people will come and ask for it, and when that happens
> we better have the tools ready.

---

From: "Patrik Fältström" <[email-masked]>
Date: Thu, 29 Dec 2016 10:23:32 +0100

> pay enough attention to incentives and barriers.  I wish it were

I completely agree with this. But I also see access providers and enterprises that regardless of how they have built their networks today do run out of IPv4 space. And when they have run out they only have a few choices:

1. Add another layer of NAT

2. Buy IPv4 addresses

3. Start running IPv6

No, we are obviously not ready with [3] yet, but neither [1] nor [2] are beautiful situations, and they get worse. Specifically for the ISPs that do not have any CGN yet, but a relatively cheap router in which they terminate one or more VLANs for their customers. I encountered one such access provider yesterday btw.

And that is why I still see [3] coming, but not yet. We are getting closer every year though because the number of things that do need IPv4 addresses increase. And even a NAT box do not decrease the number of IPv4 addresses much due to the number of concurrent flows from clients.

Because of this, I still think we must make [3] easier, because when people really need IPv6 we must be done.

   Patrik

---

From: S Moonesamy <[email-masked]>
Date: Thu, 29 Dec 2016 02:43:18 -0800

Hi David, Patrik,
At 20:27 28-12-2016, David Conrad wrote:
>Do you have some magic wand that can make that 
>happen?  It would seem the opposite is happening 
>-- the price for IPv4 addresses is climbing, 
>with rumors of some folks trying to corner the 
>market. This is, of course, unsurprising given 
>Economics 101 and the laws of supply and demand. 
>Should make for interesting times ahead for 
>those organizations that continue to demand IPv4 addresses.

There are interesting time ahead for anyone interested in the topic.

>My suspicion (hope?) is that the increased price 
>of IPv4 (and operational challenges dealing with 
>GGNAT) will encourage folks to take IPv6 more seriously.

The opportunity to take IPv6 seriously was not 
taken seriously.  I doubt that moving to IPv6 
will be about technical challenges.

At 23:17 28-12-2016, Patrik Fältström wrote:
>...in combination with the increased a. 
>announcements of unannounced (regardless of 
>whether it is allocated or not) address space; 
>and ultimately b. announcements of address space 
>that is announced (as people will just not care 
>if someone on the other side of the planet use the space or not).

The thread at 
https://lists.afrinic.net/pipermail/rpd/2016/006129.html may be informative.

Regards,
S. Moonesamy

---

From: Lee Howard <[email-masked]>
Date: Thu, 29 Dec 2016 10:28:19 -0500

>> pay enough attention to incentives and barriers.  I wish it were

Lessons learned, and captured in draft-iab-protocol-transitions-04

>
>I completely agree with this. But I also see access providers and
>enterprises that regardless of how they have built their networks today
>do run out of IPv4 space. And when they have run out they only have a few
>choices:
>

These are not alternatives, but complementary elements to an overall
strategy.

Running IPv6 doesn¹t mean you don¹t need to buy addresses or deploy NAT.
It may reduce the amount your NAT is used (esepcially useful for those
applications that don¹t play well with NAT). It might reduce the number of
addresses you need to buy (if your addresses are being used on the outside
of your NAT).
The value of running IPv6 increases over time.

>
>No, we are obviously not ready with [3] yet,

I don¹t understand this statement, since thousands of access providers and
enterprises are running IPv6. As reported by Mr. Vyncke, users in 20
nations use IPv6 10% of the time to get to IPv6-enabled sites; that¹s only
a fraction of the number of users who have IPv6 capability. Most people in
Belgium use IPv6, and about 1/3 of users in four other countries use IPv6.

I don¹t see how this is a failure, or how IPv6 isn¹t ready.

>
>And that is why I still see [3] coming, but not yet. We are getting
>closer every year though because the number of things that do need IPv4
>addresses increase. And even a NAT box do not decrease the number of IPv4
>addresses much due to the number of concurrent flows from clients.

Things. The only things that don¹t support IPv6 are Things.
Okay, there are a couple of apps (Skype) and sites (Amazon, Microsoft,
Twitter), though cloud and CDNs are coming along now. I¹ve been predicting
2018 as The Tipping Year for IPv6 for about five years, and I¹m standing
by it. 

>people really need IPv6 we must be done.

In what ways is it difficult to ³Start running IPv6²?
We even have guidance on this in RFC7381 ³Enterprise IPv6 deployment
Guidelines.² 

Lee

---

From: John C Klensin <[email-masked]>
Date: Thu, 29 Dec 2016 10:52:32 -0500

--On Thursday, December 29, 2016 10:23 +0100 Patrik Fältström
<[email-masked]> wrote:

>> I don't particularly dislike IPv6, I just think we've failed
>> to pay enough attention to incentives and barriers.  I wish
>> it were otherwise, really I do.
> 
> I completely agree with this. But I also see access providers
> and enterprises that regardless of how they have built their
> networks today do run out of IPv4 space. And when they have
> run out they only have a few choices:
> 

Actually, two more options:

4.  Run IPv6 (exclusively) in their backbones, converting to
IPv4 islands at their boundaries.  The mechanism may be a
variation on NAT, but the architecture is different.  

5. Run <something-else> in their backbones, converting to IPv4
islands at the boundaries.  It isn't very hard to think about
candidates for <something-else> given that there is no
requirement for interoperation with other ISPs and the key
requirement is support for semi-permanent virtual circuits (or,
if one prefers, channels or tunnels).

Of those five cases, only your (3) implies even the possibility
of end-to-end IPv6.  

The flaw in an analysis involving those options is the notion
that we've got a very large number of ISPs with multiple and
varied interconnection arrangements, many hosts and sites that
are multihomed in the traditional sense of advertising one set
of endpoint addresses to the network and letting the routing
system sort things out, etc.  However, my impression is that we
are seeing increasing ISP concentration (except, maybe, close to
the edges of the network, where it makes little difference) and
less of that traditional type of multihoming.  The latter might
actually be driven by IPv4 address scarcity, but the
alternatives (and alternatives to multiple-prefix IPv6
multihoming) have significant operational advantages too.

> No, we are obviously not ready with [3] yet, but neither [1]
> nor [2] are beautiful situations, and they get worse.

Note that I'm not arguing that (4) or (5) are beautiful either,
only that they (plus (1)) may look more attractive than
large-scale IPv6 deployment to the edges on any give morning,
and perhaps on any given day that is not an IPv6 flag day.

A comparison to the deployment of IPv4 may be helpful.  That
deployment incorporated, among other things, the following
characteristics for which there is no IPv6 equivalent that I can
find:

(i) The network was much smaller, much more homogeneous, and
much more operated on a technical basis and with engineering
criteria rather than economic or political ones.

(ii) The new addressing arrangement came with new protocols that
were seen as having significant advantages for interoperability
and network usability.

(iii) The network, measured in any of number of hosts, number of
users, or traffic volume, was much more about peer-to-peer
communications rather than about content distribution or even
many-client/ concentrated server operations.

(iv) The current router-based model had not yet become
completely dominant, so end-to-end really meant end-to-end,
significantly increasing the importance of a global address
space with globally-unique addresses. 

(v) Applications protocols were very diverse and their numbers
appeared seemed to be growing (in contrast with "let's run this
over the web, or at least Port 80 / 8080, too").  That diversity
and growth made ALG-type solutions unattractive because they
would inhibit the development and deployment of new
applications.  "Run it over the web" not only facilitates
firewall traversal, it lowers the bar to a collection of
networks interconnected by ALGs.

(vi) There was a flag day.

While the latter was certainly significant in promoting /
forcing a speedy transition rather than one that dragged out for
many years, I believe the other issues were very important too,
at least in avoiding massive pushback to IPv4 transition.

> Specifically for the ISPs that do not have any CGN yet, but a
> relatively cheap router in which they terminate one or more
> VLANs for their customers. I encountered one such access
> provider yesterday btw.
> 
> And that is why I still see [3] coming, but not yet. We are
> getting closer every year though because the number of things
> that do need IPv4 addresses increase. And even a NAT box do
> not decrease the number of IPv4 addresses much due to the
> number of concurrent flows from clients.

That is where our analyses differ a bit ... and differs more the
more we see the network in terms of concurrent flows from a
large number of clients to a small number of servers (or server
clusters).  If we were designing an optimal network architecture
for a CDN, especially a provider-optimized CDN, I suggest it
wouldn't look much like IPv6 or evem IPv6.  

> Because of this, I still think we must make [3] easier,
> because when people really need IPv6 we must be done.

We certainly agree about the "must make (3) easier" part.  A
different way of stating my concern is that, each few years that
pass when we have not widely deployed IPv6 and have figured out
way to control the pain, the more we may create the perception
that we can manage without IPv6 forever.  Whether that is true
or not, the assumption tends to drive decisions whose
side-effect is driving the perceived pain of IPv6 conversion up.

    john

---

From: "John Levine" <[email-masked]>
Date: 29 Dec 2016 16:18:37 -0000

>enterprises are running IPv6.

There are still all sorts of places that things that are easy and
painless with IPv4 are much too hard with IPv6.

Here's an example: in my house I have a network behind a router
connected to Time-Warner cable.  T-W gives me one IPv4 address so my
router NATs.  I configured it once to use 192.168.80.0/24 and it works
great.  I have a separate server running DHCP and DNS and some other
local services.  It hands out fixed addresses for devices like
printers and the backup server, and dynamic ones for devices like
phones.  The DNS cache (unbound) knows names for all of the fixed
address devices, and handles queries from devices on the LAN, which
are all configured by DHCP to use it.  This took about an hour to set
up.

T-W apppears to give me a /48 of IPv6 addresses, so every time my
router reboots it picks a /64 at random out of that /48, and all of
the IPv6 addresses on my LAN change.  There is probably some way to
tell the router, a linux based Ubiquiti Edgerouter, to pick the same
v6 /64 every time, but I can't figure out what it us.  It was hard
enough to reverse engineer the router config to make SLAAC work at
all.  Maybe I should use DHCPv6, but I'd have to figure it out on the
server side, and then see how well all of my devices support it.

If IPv6 is going to be useful, I also need a v6 DNS cache.  Since the
global v6 addresses are unstable, I set the cache to answer on link
local address FE80::2, and set the router announcements to announce
it.  All set?  Nope.  That's a link-local address so the address is
actually FE80::2%xxx where xxx is each device's LAN interface, and
devices do a generally rotten job of appending the interface name to
the address they get from SLAAC.  I might be able to use ULAs but I
have no idea how well ULAs actually work and how I would set them up
on my servers, so my DNS cache is at 192.168.80.2 and will stay there
for the indefinite future.

Perhaps there are ways to deal with all of these, but I am a fairly
sophisticated network operator, and I doubt I am all that much less
competent than everyone else.  So when people say IPv6 still isn't
ready for prime time, they're not kidding.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 29 Dec 2016 16:27:21 -0000

> ...  However, my impression is that we
>less of that traditional type of multihoming.

There's tons of multihoming.  Every medium sized or larger business
wants multiple upstreams for reliability.  They typically get a chunk
of PA IPv4 addresses from each upstream.

This is a big reason why providers don't implement BCP38.  A customer
has one block of addresses from provider A and another from provider
B.  In general each provider only knows about its own address block,
but the traffic comes from both blocks, and the customers get rather
annoyed if a provider doesn't accept their traffic.  ("If you don't
want our $20K/month, we're sure we can find someone else who does.")
Trying to keep track of what customer has what block of someone else's
address space is hopeless, so they just turn off the filters for the
multihomed customers.

This is of course a place where v6 wins, since the customer can
get their own block of PI space, but then there's all those other
v6 deployment problems.

R's,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Dec 2016 08:27:20 +1300

John,

> I might be able to use ULAs but I have no idea how well ULAs actually work

Exactly like any other global-scope IPv6 address. They just work. (I speak
from experience.)

> and how I would set them up on my servers.

If you want static addresses on your servers, it's no different from any other
static address. But maybe I am not understanding your concern.

Regards
   Brian Carpenter

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Dec 2016 08:38:43 +1300

On 30/12/2016 05:27, John Levine wrote:
> get their own block of PI space, 

True, for large sites, but this solution doesn't scale to tens of millions
of customers. For that market, running with several PA prefixes is the answer
(not a problem, although we're still tuning, e.g. RFC 8028).

> but then there's all those other
> v6 deployment problems.

I'm not saying that those problems are FUD, but they are surmountable. They're
just different from all those v4 deployment problems that people solved some
years ago.

As has been said often enough, users need an incentive to invest in solving
those problems. It will come. Much more slowly than we expected in 1994, but
it will come. I see no reason to panic.

    Brian

---

From: Mark Andrews <[email-masked]>
Date: Fri, 30 Dec 2016 10:48:12 +1100

> ready for prime time, they're not kidding.

It sounds like you want a homenet router.

Mind you a lot of this would be a non-issue if hosts used the DNS
to its full potential by updating their own addresses in the DNS
using SIG(0) signed UPDATE messages when their addresses change.
SIG(0) signs using the private half of a KEY record installed in
the DNS, at the machines name, when the machine was named.  This
would be done using a TSIG signed update (think key name and password)
for the zone.

You then end up with

host.example.net KEY ...
host.example.net AAAA ...
host.example.net AAAA ...
host.example.net A ...

and you configure the nameserver to allow UPDATE messages signed
with host.example.net to update host.example.net.  This policy can
be specified in named like this.  I would expect that other vendor
can do similar.

key example.net.key {
	algorithm "hmac-sha256";
	secret "xxxxxxxxxxxxxxxxx";
};

zone example.net {
	type master;
	file "example.net.db";
	update-policy {
		grant example.net.key subdomain example.net KEY;
		grant * self * A AAAA;
	};
};

Microsoft do something similar using AD and GSS-TSIG instead of
SIG(0).  You use the domain password to perform the initial
registration of the machine after that it updates its own addresses.
This just stores all the keying data in the DNS rather than extenally.

Now it is possible to allow adding of SRV records.

	grant * selfsub * A AAAA SRV;

which allows to "_foo._bar.host.example.net. SRV ..." to be added.

This functionality has existed for over a decade now.  This is not
new.  It flows logically from combining RFC 2136, RFC 2845 and RFC
2931.

It would be possible to specify a policy which allows for a KEY
record to be added if there is no existing records at a name from
a given address range over TCP.  This would allow for self registration
of devices without having to use a adminstrative key.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "John R Levine" <[email-masked]>
Date: 29 Dec 2016 18:56:26 -0500

> It sounds like you want a homenet router.

Possibly, but I'd rather have a v6 network where the addresses hold still.

> using SIG(0) signed UPDATE messages when their addresses change.

That would be swell except the DNS server's address changes, too.

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Fri, 30 Dec 2016 11:39:32 +1100

> Possibly, but I'd rather have a v6 network where the addresses hold still.

Well there are routers that do keep internal prefixes stable.  It
isn't that hard to say interface A has 0 in bits 49 to 64 and
interface B is 1 in bits 49 to 64 etc.  This works with almost any
prefix length the ISP gives you by filling in the least significant
bits.  Then as long as you get the same prefix from the ISP all
your addressing is stable even without ULA.

With ULAs you can assign the /64's to each interface.  This doesn't
prevent PA prefixes co-existing with the ULAs.

> That would be swell except the DNS server's address changes, too.

So what.  The DNS server's addresses are in the DNS so UPDATEs still
work.  Normally a router will be a recursive DNS server so it can
advertise its own addresses via DHCP and RA or it will learn recursive
server addresses these ways and re-advertise them on its local
links.

There is NOTHING but inertia stopping the entire DNS being securely
dynamically updated over the DNS.  That includes updating DS, NS
and glue addresses records in parent zones.  The only thing that
needs longer term stability are the root servers.  Even they can
change slowly.

Nameserver can learn when they have new addresses and send out
signed UPDATE messages to update glue records in parent zones.  We
can even redirect these update messages to specialised machines
that just process the update messages.  We even have a SRV prefix
defined to allow a zone operator to do this.  Apple (with DYN I
believe) registered this about a decade ago now.  They did that to
allow CPE's routers to register their public addresses in the DNS
when they were updated via DHCP.  This works equally well for IPv4
or IPv6.

It isn't that hard to figure out the addresses of DNS servers.  We
do that all the time to send out NOTIFY messages.  There is no need
for a slave server to have a hard coded list of addresses to transfer
the zone from.  It is just intertia at this stage.  Adding this
functionality to named has been on my todo list for years now. It's
just not got to the top.  It can use the last signed NOTIFY source
address or lookup the master server's addresses in the the DNS by
name.  TSIG will prevent transfers false masters succeeding.

Mark

---

From: Mark Andrews <[email-masked]>
Date: Fri, 30 Dec 2016 12:57:09 +1100

> address space is hopeless, so they just turn off the filters for the

BCP38 should be automatable at the edge even with multihoming.  We
do have the technology to provide each customer with a CERT that
says they have been assigned this block of addresses.  This CERT
can be presented to the other providers along with a signed request
to say please accept this range of addresses over this interface.
This doesn't have to be done using BGP.  Machines can process these
without a human being involved.  It just requires willingness to
do this.

Embrace the technology.

---

From: "John R Levine" <[email-masked]>
Date: 29 Dec 2016 20:58:46 -0500

> says they have been assigned this block of addresses.

We do?  References, please, preferablyt with the commands I type into my 
router to automatically import and handle the certs.

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Fri, 30 Dec 2016 13:32:27 +1100

In message <[email-masked]>, "John R Levine" writes
> router to automatically import and handle the certs.

John read what I said not what you think I said.

We do have the technology to provide a CERT to every customer.  See SIDR.
We do have the ablity it verfiy these CERT and use them with BGP. 
We should be able to do this with other protocols.
These CERTs could be used to generate BCP38 filters.  This could be all
automated.

We have people complaining that BGP38 is hard for multi-homing
because it is a manual process of verifying each customers address
allocation.  Once you have a verified allocation the rest really
is a mechanical process.  The building blocks now exist for it to
be easy.  We should be using them.  There is NOTHING stopping ISP's
generating these CERTs today.  Just passing a request to accept
these addresses signed with the CERT to the other ISP would
significantly reduce the amount work required as well as the amount
of fraudulent requests.  A fax with faked letter head is so much
more secure, not.

There are lots of brainy engineers at router vendors that could
design a scheme to remove humans from this process.  I can think
of several methods to do this but I'm not a router vendor so I
don't have the ability to materialise the idea.

Mark

---

From: Randy Bush <[email-masked]>
Date: Fri, 30 Dec 2016 11:39:08 +0900

it's fun to have this discussion all over again, for some value of fun.
in this case, i agree with john, we do not make it easy.  that so many
reply with 'advice' qed.

but for some possibly new data on the embarrassing large extent of cgn
deployment, here is the book

    "A Multi-perspective Analysis of Carrier-Grade NAT Deployment:"
    Philipp Richter (TU Berlin), Florian Wohlfart (Technische
    Universität München), Narseo Vallina-Rodriguez (ICSI), Mark Allman
    (ICSI), Randy Bush (Internet Initiative Japan), Anja Feldmann (TU
    Berlin), Christian Kreibich (ICSI /Lastline), Nicholas Weaver
    (ICSI), Vern Paxson (ICSI / UC Berkeley)
    https://dl.acm.org/citation.cfm?id=2987474  (no paywall)

and the movie

    https://ripe73.ripe.net/archives/video/1244/

randy

---

From: Randy Bush <[email-masked]>
Date: Fri, 30 Dec 2016 11:42:10 +0900

> We do have the technology to provide a CERT to every customer.  See

see frequent residential address reassignment

---

From: "John Levine" <[email-masked]>
Date: 30 Dec 2016 02:47:19 -0000

>see frequent residential address reassignment

That's not really a problem, since vanishingly few resi customers are
multihomed.  The problem occurs with customers who are big enough to
be multihomed but not so big that they have a staff that knows all
of the magic of BGP and expensive routers.

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Fri, 30 Dec 2016 14:05:18 +1100

> of the magic of BGP and expensive routers.

And it should be possible for a router to request a CERT for the
addresses is it allocated by ISP A along with their assignment
and provide it to ISP B, ISP C ...  It just needs to supply
a public key for a private key it knows so the allocation process
can fill in the rest of the details and sign it.

Whether this ever gets down to residential equipement I don't know
but it would theoretically work.  There is no reason it couldn't
work.

Mark

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Dec 2016 16:16:19 +1300

> of the magic of BGP and expensive routers.

Which is exactly why we have to make multi-prefix multihoming work
out of the box. Which is why we have RFC 7157 and RFC 8028
and draft-ietf-rtgwg-dst-src-routing, and we're not done yet.

   Brian

---

From: Michel Py <[email-masked]>
Date: Fri, 30 Dec 2016 03:42:15 +0000

Brian,

> Brian E Carpenter wrote :
> Which is exactly why we have to make multi-prefix multihoming work out of the box. Which is why we
>have RFC 7157 and RFC 8028 and draft-ietf-rtgwg-dst-src-routing, and we're not done yet.

We have missed the delivery date by 14 years. 

Michel.

---

From: John C Klensin <[email-masked]>
Date: Thu, 29 Dec 2016 22:48:57 -0500

--On Thursday, December 29, 2016 16:27 +0000 John Levine
<[email-masked]> wrote:

>> are seeing increasing ISP concentration (except, maybe, close
>> to the edges of the network, where it makes little
>> difference) and less of that traditional type of multihoming.
> 
> There's tons of multihoming.  Every medium sized or larger
> business wants multiple upstreams for reliability.  They
> typically get a chunk of PA IPv4 addresses from each upstream.

John,

See Brian's comments and some others for responses to what I
think was intended to be your main point.  However, I picked my
words carefully.  I said and meant "traditional type of
multihoming" and, more important in the previous sentence, "many
hosts and sites that are multihomed in the traditional sense of
advertising one set of endpoint addresses to the network and
letting the routing system sort things out".   That is, very
specifically, one address per host, advertised to multiple ISPs/
networks/ paths and not "a chunk of PA IPv4 addresses from each
upstream".  

You are talking about a different --architecturally different--
approach, one that either requires endpoint hosts to manage
different addresses and the routing options associated with each
or that requires NAT arrangements that map one-many or many-many
rather than many-one or one-one.   

I'm not going to argue that one approach is better or worse than
the other.  In particular, unless one is large enough enterprise
to arrange for PI space and for multiple providers to route it,
the traditional multihoming architecture is effectively dead.
But that is another change in the architecture of the network as
it actually functions that we are, to at least some extent,
pretending is not happening.

best,
    john

---

From: "John R Levine" <[email-masked]>
Date: 30 Dec 2016 00:12:02 -0500

> I said and meant "traditional type of

But it's the same thing -- the customer numbers some of their network with 
PA addresses from one provider and part of it with PA addresses from the 
other.  Then the customer sends out traffic from both address blocks to 
both interfaces, and the upstreams can't tell whether an unknown address 
is a legit one from another provider or a malicious spoof.

I'm pretty sure this is right, having talked to ISPs about it in the 
context of why BCP38 is harder than you'd think.

R's,
John

---

From: [email-masked]
Date: Fri, 30 Dec 2016 00:18:51 -0500 (EST)

> Possibly, but I'd rather have a v6 network where the addresses hold still.

Can this not be accomplished with a port 41 tunnel, a nameserver, some 
hardcoded static routes, and a router advertisement daemon on your 
existing NAT device?

---

From: "Patrik Fältström" <[email-masked]>
Date: Fri, 30 Dec 2016 08:36:01 +0100

[Responses to John and Lee in the same email]

On 29 Dec 2016, at 16:52, John C Klensin wrote:

> 4.  Run IPv6 (exclusively) in their backbones, converting to IPv4 islands at their boundaries.  The mechanism may be a

This implies NAT64 but I do not see that be closer in evolution than other alternatives. And hard to deploy in combination with for example DNSSEC. It further sets quite high requirements not only on the NAT64 operator on how the network is deployed, provisioning systems etc.

So, yes an alternative in theory but not in reality.

> 5. Run <something-else> in their backbones, converting to IPv4 islands at the boundaries.  It isn't very hard to think about candidates for <something-else> given that there is no
> requirement is support for semi-permanent virtual circuits (or, if one prefers, channels or tunnels).

Actually, I have very hard problems finding what <something-else> is that you can deploy, find hardware, software and provisioning software for. Do you have any suggestions?

> Of those five cases, only your (3) implies even the possibility of end-to-end IPv6.

I would add that [3], [4] and [5] all three imply running IPv6 to the end user. And that is not cooked yet. See below.

> A comparison to the deployment of IPv4 may be helpful.  That deployment incorporated, among other things, the following
> characteristics for which there is no IPv6 equivalent that I can find:

Agree.

That said, the largest problem with IPv6 deployment is that I find so many mistakes be done at or close to the edge. The access provider was forgotten.

> That is where our analyses differ a bit ... and differs more the more we see the network in terms of concurrent flows from a
> large number of clients to a small number of servers (or server clusters).  If we were designing an optimal network architecture for a CDN, especially a provider-optimized CDN, I suggest it wouldn't look much like IPv6 or evem IPv6.

So you choose [1]?

> We certainly agree about the "must make (3) easier" part.  A different way of stating my concern is that, each few years that pass when we have not widely deployed IPv6 and have figured out way to control the pain, the more we may create the perception that we can manage without IPv6 forever.  Whether that is true or not, the assumption tends to drive decisions whose

Yes!

And on top of this, the alternatives to [3] are also used for higher lock-in of customers, building silos (specifically when eye balls communicate with fewer and fewer clouds), and other things that act against open Internet but in favor of market economy driving forces.

> Lessons learned, and captured in draft-iab-protocol-transitions-04

Agree and in this case I claim specifically 4.1 is interesting.

> These are not alternatives, but complementary elements to an overall strategy.

Yes and no. [1] and [2] do not imply deployment of IPv6. [3] (and [4], [5] of Johns proposal) imply deployment of IPv6 at edge. Deployment of IPv6 at edge of an ISP is hard.

First of all, remember that every access customer, except cellphone networks, that run IPv4 already have one layer of NAT. What you talk about here is adding a 2nd layer of NAT. In cellphone networks there was at first no NAT, but is now in most cases. Growth of end nodes have been on mobile data networks.

> It may reduce the amount your NAT is used (esepcially useful for those applications that don¹t play well with NAT). It might reduce the number of addresses you need to buy (if your addresses are being used on the outside of your NAT).

Somewhat, yes, of course you are right. But, the step to add a 2nd layer of NAT for an access provider is not easy.

> I don¹t understand this statement, since thousands of access providers and enterprises are running IPv6.

Not really...

> As reported by Mr. Vyncke, users in 20 nations use IPv6 10% of the time to get to IPv6-enabled sites; that¹s only a fraction of the number of users who have IPv6 capability. Most people in Belgium use IPv6, and about 1/3 of users in four other countries use IPv6.

I disagree.

I see IPv6 deployment:

a. At some cellphone providers. It is ready to add IPv6 in the cellphone network(s) as long as you as a provider do have some control (or understand) how the handsets work.

b. Enterprises that did have fixed IPv4 address, i.e. one router port per customer.

c. Hosting providers, because they in reality are like [b].

But we do not see deployment of IPv6 in general:

d. In DSL-based networks.

e. In FTTH (and similar) networks where DHCP in various split VLAN based L2 domains are in use.

[d] just because it was never implemented.

[e] just because IETF never really did agree on how to handle zero-conf. Too many alternatives, and definitely not "as easy" as setting DHCP helper address. This in turn lead to complications in the CPE management. You can not even today "buy a CPE and plug it in".

> I don¹t see how this is a failure, or how IPv6 isn¹t ready.

Zeroconf and IPv6 is a mess.

> I¹ve been predicting 2018 as The Tipping Year for IPv6 for about five years, and I¹m standing by it.

That I agree with, but the zeroconf must be cleaned up. Specifically in implementations. As easy for an access provider as allocation of a subnet for a VLAN and then add DHCP helper address to the interface.

> We even have guidance on this in RFC7381 ³Enterprise IPv6 deployment Guidelines.²

I am not talking about Enterprise. That is ready.

You say in 7381:

> Last but not least, one of the most important design choices to make
> while deploying IPv6 on the internal network is whether to use SLAAC
> [RFC4862], the Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
> [RFC3315], or a combination thereof.

To be blunt, as long as there is a choice, we will not see large deployment.

   paf

---

From: Randy Bush <[email-masked]>
Date: Fri, 30 Dec 2016 18:31:39 +0900

> This implies NAT64 but I do not see that be closer in evolution than
> other alternatives.

the ietf meeting noc has been asked to push nat64/dns64 a bit harder.
we are trying to get beefier and redundant a10s.  if so, we'll ask folk
to seriously exercise it, just to get some experience, document what
works and what does not, etc.

> I see IPv6 deployment:
> a. At some cellphone providers.

and massive cgn :(

> To be blunt, as long as there is a choice, we will not see large deployment.

there is no choice.  in all but greenfield, dhcp rules.  and, in the big
enterprises, exit control is big.

randy

---

From: heasley <[email-masked]>
Date: Fri, 30 Dec 2016 16:33:40 +0000

> enterprises, exit control is big.

control in address assignment is useful - what MAC receives what - for nearly
all but the most simple network, imo.  how is that done with slaac?

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 31 Dec 2016 09:08:19 +1300

[Responses to several people in the same email]

> [Responses to John and Lee in the same email]
...
> [e] just because IETF never really did agree on how to handle zero-conf. Too many alternatives, and definitely not "as easy" as setting DHCP helper address. This in turn lead to complications in th…

If you are talking about consumer CPEs, you certainly can.

> Zeroconf and IPv6 is a mess.

Please be more specific. What doesn't work that you want to work? And which of
those things will not be addressed by homenet?

...
>>> To be blunt, as long as there is a choice, we will not see large deployment.

If you're talking about enterprises, I don't see that. (Unless enterprise
network managers are as stupid as Buridan's ass*, that is.)

>> enterprises, exit control is big.

Well, enterprises or campuses that run DHCP for v4 and SLAAC for v6 are far
from unknown. But yes, exit control is desirable, so most likely DHCPv6
will "win" in a large part of the market.

> all but the most simple network, imo.  how is that done with slaac?

It isn't. So what? If that's your requirement, run DHCPv6. Your Android users
can complain to whoever it is that supports Android.

Regards
   Brian

* https://en.wikipedia.org/wiki/Buridan's_ass

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 31 Dec 2016 09:13:28 +1300

> We have missed the delivery date by 14 years. 

Well, there never was an exact delivery date, once NAT44 arrived to quell
the demand for IPv4 addresses. But the reason this is late is that it is
(IMNSHO) the hardest problem in datagram networking with free-market competition
between providers. And has been since 1974 when Louis Pouzin first mentioned it.

   Brian

---

From: "Patrik Fältström" <[email-masked]>
Date: Fri, 30 Dec 2016 21:47:43 +0100

> those things will not be addressed by homenet?

Is SLAAC+NDP, DHCPv6+NDP or DHCPv6-PD to be used for prefix allocation?

Or something else?

I am pretty sure Homenet is working on this.

But that is exactly my point when I say that IPv6 must be *really* ready the day when people will ask for it.

And when I say we should use the fact we do have some time to refine the specifications, implementations and deployment so that we are ready when CPEs start to really implement IPv6 in whatever way Homenet is specifying.

   paf

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 31 Dec 2016 07:20:31 +0900

> We have missed the delivery date by 14 years.

I wrote:

	https://tools.ietf.org/html/draft-ohta-e2e-multihoming-00

in April 2000 and I know it is stupid to use source routing for
multihoming. So, never deliver it.

All we need is transport/application layer capability to treat
multiple source and destination addresses and implementations
of such TCP has been available since 2003 or so, more than 14
years ago.

							Masataka Ohta

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 31 Dec 2016 11:52:28 +1300

> I am pretty sure Homenet is working on this.

Yes. Including running code, to my understanding**. HNCP (RFC7788) does prefix
allocation and assumes DHCPv6-PD for prefix distribution. (We also support
DHCPv6-PD in draft-ietf-anima-prefix-management, but that is ongoing work.)

> And when I say we should use the fact we do have some time to refine the specifications, implementations and deployment so that we are ready when CPEs start to really implement IPv6 in whatever way…

For homenets that need subnets, of course. I'm not panicking, however: when it's ready,
it will be used. There's no flag day.

    Brian

** http://toreanderson.github.io/2015/10/11/making-a-homenet-router-out-of-openwrt.html

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 31 Dec 2016 13:25:31 +1300

> of such TCP has been available since 2003 or so, more than 14

I am very suspicious of any claim about "all we need" in this area, but
I have written about this in some detail elsewhere:
http://www.sigcomm.org/node/3484

   Brian

---

From: Randy Bush <[email-masked]>
Date: Sat, 31 Dec 2016 14:18:42 +0900

>> control in address assignment is useful - what MAC receives what -
>> for nearly all but the most simple network, imo.  how is that done
>> with slaac?
> It isn't. So what? If that's your requirement, run DHCPv6. Your
> Android users can complain to whoever it is that supports Android.

for some silly reason, my customers don't think they pay me for
blame shifting.  they just want things to work.

and, let me repeat for the fourth time, enterprises of scale use
dhcp to drive clients to the desired exit.  dhcp6 does not let
them do that.  without feature parity we don't get to play.

randy

---

From: Octavio Alvarez <[email-masked]>
Date: Fri, 30 Dec 2016 23:54:36 -0800

On 12/30/2016 02:20 PM, Masataka Ohta wrote:

> multihoming.

Is source routing bad in general or is it bad only in multihoming scenarios?

Thanks.

---

From: Stewart Bryant <[email-masked]>
Date: Sat, 31 Dec 2016 12:22:10 +0000

> Is source routing bad in general or is it bad only in multihoming scenarios?

When called segment routing it is accepted as a useful technology for  
well defined problems of this type.

- Stewart

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 31 Dec 2016 22:30:08 +0900

> Is source routing bad in general or is it bad only in multihoming scenarios?

Source routing is bad in general and, especially, in multihoming
scenarios involving complex topology, such as hierarchical multiple
prefixes involving TLAs, NLAs and SLAs.

Moreover, source routing is unnecessary, because currently specified
source address selection of IPv6 is stupid.

Despite all the weasel wordings of IPv6 specifications, the only
proper way for source address selection for IPv6 (and IPv4) is to
distribute source prefixes by route entries of routing protocols,
which means, if a destination address is selected, the corresponding
destination address becomes uniquely obvious. Or, an alternative
(assuming IPv6++) is to make it unnecessary by source locator
rewriting with locator ID separation.

Anyway, multi6 WG utterly failed because most of the members (including
chairs) failed to understand that *TIMELY* multihoming needs notions
of timeout and, thus, connections, which is available only at the
transport layer or above. Instead, multi6 WG, stupidly enough, tried
to solve the problem at the IP layer in vain, where there can be no
connection timeout.

That's what I wrote from the beginning that:

    To support the end to end multihoming, no change is necessary on
    routing protocols. Instead, APIs and applications must be modified to
    detect and react against the loss of connection.  In case of TCP
    where there is a network wide agreement on the semantics of the loss
    of connectivity, most of the work can be done by the kernel code at
    the transport layer. However, in general, the condition of "loss of
    connectivity" varies application by application that the multihoming
    must directly be controlled by application programs.

in

Note that routing protocol change denied in the quoted paragraph
of mine becomes necessary only if proper source address selection
is necessary.

							Masataka Ohta

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 1 Jan 2017 08:20:52 +1300

> of timeout

No doubt that is why shim6, the direct result of multi6, includes probes, a
keepalive timeout and discussion of what to do if failure occurs even during
context creation. Shim6 has not suceeded, but misunderstanding the need for
timeouts and probes was not the reason. There is some further discussion of
this issue, with experimental and simulation results, in
https://tools.ietf.org/html/draft-naderi-ipv6-probing-01 .

I have never found it very helpful to accuse discussion partners of stupidity.

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 1 Jan 2017 08:46:15 +1300

...
> well defined problems of this type.

Please be careful with terminology, though. In the multihoming context, we aren't
talking about source routes set by the host. We're talking about source-address
based routing implemented by the routers; there is no source route in the packet.
That's why it's usually abbreviated as SADR.

In segment routing, there is a source route in the packet. Different animal.

     Brian

---

From: David Farmer <[email-masked]>
Date: Sat, 31 Dec 2016 13:50:29 -0600

On Fri, Dec 30, 2016 at 11:18 PM, Randy Bush <[email-masked]> wrote:
...

> them do that.  without feature parity we don't get to play.

I'm not getting exactly what you are saying.

When you say "use dhcp to drive clients to the desired exit", which exit do
are you referring to?  The local subnet exit, AKA the local exit router?
Or, are you referring to an enterprise level exit?

But, I agree there are several problems with DHCPv6 and its parity with
DHCPv4, and this is a serious barrier to enterprise adoption of IPv6.  My
favored to harp on is that they use different primary keys to identify a
host, DHCPv4 uses MAC address and DHCPv6 uses DUID.  I understand why, but
it is still an operational nightmare.

Thanks.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 1 Jan 2017 09:07:09 +1300

> blame shifting.  they just want things to work.

Yes. So not implementing DHCPv6 might be a self-defeating decision
by an operating system developer, don't you think?

> dhcp to drive clients to the desired exit.

Excuse my ignorance, but which DHCP options does that involve?

> dhcp6 does not let

Which is why I think RFC 8028 has value.  It's intended to
support exit selection via first-hop selection.

    Brian

---

From: Jeff Tantsura <[email-masked]>
Date: Sat, 31 Dec 2016 13:37:53 -0800

Segment Routing is as much source routing as RSVP-TE would be, there’s no per hop SA lookup, but rather per FEC (that could be a SA) at the ingress.
Ability to abstract next hop into higher layer, locally resolvable entity (adj-sid -> node->sid -> anycast-sid -> etc) provides a rather viable from a network design and implementation way to have end2end networking while utilizing local state.
 
Cheers,
Jeff

On 12/31/16, 04:22, "ietf on behalf of Stewart Bryant" <[email-masked] on behalf of [email-masked]> wrote:

    
    
    - Stewart

---

From: "John Levine" <[email-masked]>
Date: 31 Dec 2016 23:18:11 -0000

>by an operating system developer, don't you think?

Hmmn, let's take a look at smartphone OS market share (per IDC for
3Q2016)

Windows Phone  0.3%
Apple iOS     12.5%
Android       86.8%

It appears that not implementing DHCPv6 is the key to world
domination.  Next question, please?

R's,
John

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 1 Jan 2017 08:35:13 +0900

Brian E Carpenter wrote:

> context creation.

That's the stupidity.

At the connectionless IP layer, never try to create a context, a
connection.

That's no different from poor NAT guessing validity of TCP connection
through timeout. The guess can not be complete, correct or *TIMELY*.

Moreover, as a connection at a higher layer already has proper
mechanisms for the timeout, providing an incomplete and incorrect
alternative somewhere else is totally useless.

According to the end to end argument:

	The function in question can completely and correctly be
	implemented only with the knowledge and help of the
	application standing at the end points of the communication
	system.

the knowledge and help is not available at the IP layer but is
already available at higher layers.

 > I have never found it very helpful to accuse discussion partners of

It isn't, unless shim6 members can recognize the collective
stupidity of the WG. But, that is not my problem.

						Masataka Ohta

---

From: Randy Bush <[email-masked]>
Date: Sun, 01 Jan 2017 09:25:40 +0900

> by an operating system developer, don't you think?

the developer in question is an ipv6 purist.  shooting himself in the
foot and the customers at the same time.  it's an ipv6 tradition.

>> and, let me repeat for the fourth time, enterprises of scale use dhcp
>> to drive clients to the desired exit.

code 3 in v4, router option.  folk use it to cause subsets of the space
to take different exits.

>> dhcp6 does not let them do that.  without feature parity we don't get
>> to play.
> Which is why I think RFC 8028 has value.  It's intended to support
> exit selection via first-hop selection.

that is not feature parity.  that is yet one more ipv6 'feature' that is
just different for religious reasons.  instead of giving the customer
what they want, we invent shiny new stuff and wonder why they walked
away.  it must be that they are stupid.

randy

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 1 Jan 2017 16:27:20 +1300

> code 3 in v4, router option.  folk use it to cause subsets of the space

Thanks, I was wondering whether you meant something more subtle than that.
And yes, things like draft-ietf-mif-dhcpv6-route-option and
draft-sarikaya-dhc-dhcpv6-raoptions-sadr have a sad history of being trampled.

In fact I haven't changed my mind since 2012:
https://mailarchive.ietf.org/arch/msg/mif/B6NCyw2y2O6I112TQJp_pcN_OoM

> just different for religious reasons.  

It's a solution that will work the same for SLAAC-derived and
DHCPv6-derived host addresses (and for manually assigned host addresses,
for that matter), so I don't think that is very fair. I agree that it
moves the necessary config magic from the DHCP(v6) screen to the router
screen, but the logical result is the same. Given the lemons available,
it seems like a reasonable lemonade recipe.

However (see above) I baiscally agree with you. When MIF was first proposed
I said "all we really need is a default router per prefix" and IMNSHO that's
still true.

> instead of giving the customer

Hardly, but they are sometimes a bit set in their ways. Change costs
money.

    Brian

---

From: Randy Bush <[email-masked]>
Date: Sun, 01 Jan 2017 13:37:07 +0900

> However (see above) I baiscally agree with you. When MIF was first
> proposed I said "all we really need is a default router per prefix"
> and IMNSHO that's still true.

you would think it was simple; absolutely maximize any and all feature
and configuration parity between dhcp4 and dhcp6.  between managing a
v4 an a v6 (and mixed) network in general.  but no, it goes against the
religion, the religion that has further slowed what was a designed-in
transition hell.

>> instead of giving the customer what they want, we invent shiny new
>> stuff and wonder why they walked away.  it must be that they are
>> stupid.

somehow, the ipv6 religion seems to make normally sensible folk immune
to the perception of 'customer.'

randy, who lost blood fighting idiocy such as NLA/TLA

---

From: Randy Bush <[email-masked]>
Date: Sun, 01 Jan 2017 13:44:01 +0900

> Please be careful with terminology, though. In the multihoming
> context, we aren't talking about source routes set by the host. We're
> talking about source-address based routing implemented by the routers;
> there is no source route in the packet.  That's why it's usually
> abbreviated as SADR.
> 

Lebrun, Aubry, and Bonaventure have a great paper "Realising SDN without
per-flow state in enterprise networks" using ipv6 segment routing to
provide controlled paths, exits, etc.  i can't find it on the net of a
thousand lies, so it may not have been published yet.

randy

---

From: Randy Bush <[email-masked]>
Date: Sun, 01 Jan 2017 13:45:44 +0900

> domination.  Next question, please?

you are confusing coincidence with causality