Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 6 Jan 2014 14:24:07 -0600

Hi all,

This document does not seem to have bibxml3 record, I am getting:

unable to find external file "reference.I-D.yourtchenko-ra-dhcpv6-comparison"

Regards,

Behcet

On Wed, Nov 27, 2013 at 7:06 AM, Andrew Yourtchenko <[email-masked]>wrote:

> Hello all,
>
> Finally I managed to comb a little bit and finally submit the doc that
> aims to compare RAs with DHCPv6 which emerged from the discussion on this
> list a few weeks ago.
>
> I'll be very happy to hear any comments, suggestions, flames, etc.
>
> --a
>
>
> p.s. The "realtime changes" repository is at: https://github.com/ayourtch/
> ra-dhcpv6, in case you want to send the feedback via a pull request :)
>
> ---------- Forwarded message ----------
> Date: Wed, 27 Nov 2013 04:52:14 -0800
> From: [email-masked]
> To: Andrew Yourtchenko <[email-masked]>
> Subject: New Version Notification for
>     draft-yourtchenko-ra-dhcpv6-comparison-00.txt
>
>
> A new version of I-D, draft-yourtchenko-ra-dhcpv6-comparison-00.txt
> has been successfully submitted by Andrew Yourtchenko and posted to the
> IETF repository.
>
> Filename:        draft-yourtchenko-ra-dhcpv6-comparison
> Revision:        00
> Title:           A comparison between the DHCPv6 and RA based host
> configuration
> Creation date:   2013-11-27
> Group:           Individual Submission
> Number of pages: 12
> URL:             http://www.ietf.org/internet-drafts/draft-yourtchenko-ra-
> dhcpv6-comparison-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-yourtchenko-ra-
> dhcpv6-comparison
> Htmlized:        http://tools.ietf.org/html/draft-yourtchenko-ra-dhcpv6-
> comparison-00
>
>
> Abstract:
>    This document attempts to make a balanced comparison between the RA-
>    based and DHCPv6-based host configuration mechanisms.  It compares
>    the two on different aspects, e.g: underlying media assumptions,
>    coordination, locality, etc.  and highlights the strong and weak
>    sides of both protocols for each scenario.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 07 Jan 2014 12:39:10 +1300

There's a generic problem with the bibxml3 files, with numerous
missing records. The xml2rfc people know but it's taking some time
to fix, apparently.

[email-masked] is the list for reporting such problems.

   Brian

On 07/01/2014 09:24, Behcet Sarikaya wrote:
> ------------------------------------------------------------------------
>

---

From: Matthew Petach <[email-masked]>
Date: Mon, 6 Jan 2014 19:10:57 -0800

On Sun, Dec 8, 2013 at 11:38 AM, Owen DeLong <[email-masked]> wrote:

>
> On Dec 8, 2013, at 11:22 , Brian E Carpenter <[email-masked]>
> wrote:
>
> > On 08/12/2013 19:40, Owen DeLong wrote:
> >> On Dec 7, 2013, at 22:25 , Andrew Yourtchenko <[email-masked]>
> wrote:
> >
> > ...
> >>> I think you nailed it here: With RA you *discover* the routers
> available on the link, with DHCP in legacy IP, you *configure* them.
> >>
> >> No, with DHCP, you discovered what some remote host rumored them to be.
> >
> > I don't think we should be having this argument. We should be
> > trying to write down objectively the type of scenarios where
> > DHCPv6 is applicable, the type of scenarios where RA-only is
> > applicable, and the type of scenarios where both (simultaneously)
> > are applicable.
> >
> > There's no right or wrong answer here.
> >
> >   Brian
>
> In IPv6, as I read the RFCs, there's no valid way for a host to know that
> it is supposed to get information from a DHCPv6 server unless it receives
> an RA with the M and/or O bits set.
>

[been sitting on this for several days, pondering whether or not to send
 it out.  finally decided it's not in my nature to not be impetuous, so
after
 careful consideration decided I needed to go ahead and continue to be
 impetuous, and send it out.  apologies for it now being a very stale rant.]

As I read this thread, I try to avoid banging my head into the
wall in frustration.

People seem to be replying based on a notion that the current
set of RFCs define the way the future must be.

That is not a true notion.

There are multi-billion dollar companies that have a need
to operate their networks in very specific ways.  If those
ways are not supported by the RFCs, they will pay money
to vendors to have options added to the software to allow
them to operate their networks in that way.  See for example
the filter-aaaa-on-v4 option in BIND; while there was resistance
to the idea that DNS servers be configurable to not
return quad-A records to v4 queries, in the end, the
needs of the business won out.
There is a
similar dynamic at play here.  There are very large networks
that require DCHPv6-only implementations to work, and they
will get software to support that model, one way or another,
because without it, they cannot move to a dual-stack
environment.  Not from a technical perspective, of course,
but from an accounting and control perspective; the DHCP
server must be the source of both v4 and v6 address assignments,
and the only such source, in order for the staff to know for certain
who has been assigned a given address on the network.

You can argue back and forth until you're blue in the face;
but it's rather like trying to persuade a glacier to stop
advancing by pointing a hair dryer at it.  There *will* be
networks that will be run with address assignments from DHCP only,
both for v4 and v6, and it can either happen with support from the
RFC-discussing community, or it can come via paid-for-knobs in
software to allow for non-RFC DHCPv4+DHCPv6-only environments.

Remember, RFCs are guidelines only, not laws, and
if the guidelines don't support the operational needs
of businesses, they _will_ bypass them in order to
keep the business functioning.

Very large scale enterprises are well grounded in
the model of having the host config say "obtain
addresses dynamically", and having the source
of those addresses be an authoritative box which
tracks and accounts for all addresses given out.
The notion of clients selecting their own address
does not work in those environments, and trying
to insist they alter their business to fit your idea
of how things should work is less than useful.

>
> As such, the options are not DHCPv6 only, RA-only, and Both, but, RA-only
> and Both.
>
> The scenarios where RA-Only make sense are any scenario where you do not
> need greater control of the client configuration than Prefix information,
> routing information, and DNS resolver addresses and search strings.
>
> In any scenario where you need to supply the host with more configuration
> information on a dynamic basis, DHCPv6 is also required.
>
> Also, if you want dynamic DNS updates, deterministic assigned suffixes,
> etc., these fall into the DHCPv6 realm.
>
> It's really as simple as that as near as I can tell.
>
> If you want to run without RAs, then you are into the realm of static
> configuration. I, personally, do not see this as a problem.
>

Or, you're a company with tens of thousands
of desktops, where static configuration is not
a viable option, but control over address
assignment from central servers is a must;
in that environment, DHCPv6-assignment-only is
a reality, and will exist; it is already being explored
today, and to to deny that it is coming is equally as
useful as cursing the coming of nightfall; it
will happen, with or without your agreement
or support.

Matt

> Owen

---

From: Ted Lemon <[email-masked]>
Date: Mon, 6 Jan 2014 23:11:24 -0500

On Jan 6, 2014, at 10:10 PM, Matthew Petach <[email-masked]> wrote:
> to operate their networks in very specific ways. 

If you set your routers to send RAs with the M bit set and the A bit set on any prefixes that are advertised, then devices will not autoconfigure using SLAAC (or at least, they shouldn't).   That delivers to you the exact functionality you say you want.   What change are you arguing for in addition to this?

---

From: Ted Lemon <[email-masked]>
Date: Mon, 6 Jan 2014 23:12:32 -0500

On Jan 6, 2014, at 11:11 PM, Ted Lemon <[email-masked]> wrote:
> If you set your routers to send RAs with the M bit set and the A bit set

Sorry, I meant with the A bit clear, of course.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 7 Jan 2014 13:13:54 +0900

> needs of the business won out.

I think that's a terrible example. AFAIK (and I think I was in the room)
the filter-aaaa-on-v4 hack was originally proposed for use in CPEs, and it
met with opposition even there. Opposition for getting it into bind was
pretty strong, and AIUI - as you say - it was included only because someone
said, "We have a contract. Here's a check. Now honour the contract."

In hindsight, it turned out to be a really bad idea. The hack was never
used for its intended purpose in the CPE, but it did end up being used
basically by an entire country to cling to a fundamentally broken IPv6
deployment model (the NTT walled-garden "here's a global IPv6 address and a
default route, but you can't reach the IPv6 Internet, have a nice day"
fiasco). I think that if filter-aaaa-on-v4 is an example of anything, it's
an example of the law of unintended consequences.

> There are very large networks

<sidenote>
DHCPv6 is not *necessary* accounting and control. It is one way to do it,
but you can do it just as well with address tracking in the switches.
Address tracking is also much more flexible (allowing multiple addresses,
dynamic addresses) and more secure: while using DHCP for address
verification requires strong first-hop security in the switches (DHCP
snooping, address-to-MAC binding, forced forwarding, etc) address tracking
requires none of that. In fact, there's a fallacy here: I have personally
see security people think that DHCP-provided addresses are secure, when by
themselves they are not secure at all. They can only be made secure if
first-hop security is in place.

In fact, I'd argue that DHCPv4 is not particularly well-suited for address
tracking at all, and the only reason we use DHCP for address tracking in
IPv4 is that in IPv4 there is basically no other mechanism to assign
addresses.
</sidenote>

With that out of the way: why are you talking about address assignment.
DHCPv6-only address assignment is already a standard. Send an RA with M=1
(and optionally a prefix with A=0) and - assuming your hosts implement
DHCPv6 - you're done.

> software to allow for non-RFC DHCPv4+DHCPv6-only environments.

Of course. In the privacy of your own network, or between consenting
networks and implementations, you can do whatever you like. But
standardizing it is a much higher bar. In hindsight, I think it's pretty
clear to that filter-aaaa-on-v4 is a terrible idea (just think of what will
happen to it when DNSSEC rolls around), and I think it's clear that it will
never be standardized. But that doesn't stop people from using it.

> will happen, with or without your agreement

It's not entirely clear to me what you're talking about here, since
DHCPv6-only address assignment is already possible today. But take a random
$FEATURE. If you're right and your multi-billion dollar enterprises get all
host operating systems to support $FEATURE, then it will be a de facto
standard. But until then, it would be a mistake for the IETF to to
standardize $FEATURE if there are existing and technically superior ways of
implmenting $FEATURE's functionality just because a subset of users want to
stick to the same practices they used in IPv4.

BTW, I am aware of at least one company that meets your "multi-billion
dollar, tens of thousands of desktops" definition that claims to have
brought IPv6 to 99% of its engineers without using DHCPv6 for address
assignment. In fact, they saw this as an opportunity to not run a DHCPv6
server at all.

Cheers,
Lorenzo

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 7 Jan 2014 01:47:57 -0800 (PST)

<snip>

>keep the business functioning.

And they're quite free to do that at their expense, privately inside their own network, and without any involvement of the IETF if they don't care about interoperability. They can pay all of the costs of their device vendors implementing the enterprise's own methods and protocols when they are different to the IETF's.

The thing the IETF have to worry about is summarised quite well in the title of RFC3271, and a few paragraphs from it:

"The Internet is for Everyone"

"  Internet is for everyone - but it won't be until in every home, in
   every business, in every school, in every library, in every hospital
   in every town and in every country on the Globe, the Internet can be
   accessed without limitation, at any time and in every language."

"  Internet is for everyone - but it won't be if it is too complex to be
   used easily by everyone.  Let us dedicate ourselves to the task of
   simplifying the Internet's interfaces and to educating all that are
   interested in its use."

The IETF is about providing protocols to provide interoperability between many different, independent and unrelated parties' implementations. That means that my mother's interoperability and ease of use needs are as equally important to consider as your enterprises' are, when developing a solution. 

Enterprise networks are quite welcome to bring their needs to the IETF, but I don't think they can expect that only their needs will be considered and satisfied, just because they've got lots of money. There are more home users of the Internet and home networks attached to the Internet than there are enterprises networks and users, so if there is a common case to optimise for, it is the non-technical home user. 

>tracks and accounts for all addresses given out.

DHCPv4 and DHCPv6 "tracks and accounts for all addresses given out", but it won't guarantee to tell you all addresses in use, and I think that is what mostly enterprise people actually are caring about (and I used to be one of them). DHCP does not track statically configured addresses in either IPv4 or IPv6, and in the case of IPv6, won't track link-local addresses present and in use either. DHCPv6, SLAAC, static and link-local addresses are all candidate addresses for applications to use (RFC6742, RFC4007), so DHCPv6 will only ever provide partial visibility into what addresses are in use - just as DHCPv4 does.

Give up the delusion that DHCP of either flavour will guarantee to tell you all the addresses in use on your network, and deploy a proper solution that does, such as arpwatch for IPv4, or ipv6mon (http://www.si6networks.com/tools/ipv6mon/) for IPv6. I don't know if the commercial router vendors are providing equivalent tools, but they should be if they aren't and want to address their enterprise customers' security needs.

>
>
>>As such, the options are not DHCPv6 only, RA-only, and Both, but, RA-only and Both.
>>
>>The scenarios where RA-Only make sense are any scenario where you do not need greater control of the client configuration than Prefix information, routing information, and DNS resolver addresses and search strings.
>>
>>In any scenario where you need to supply the host with more configuration information on a dynamic basis, DHCPv6 is also required.
>>
>>Also, if you want dynamic DNS updates, deterministic assigned suffixes, etc., these fall into the DHCPv6 realm.
>>
>>If you want to run without RAs, then you are into the realm of static configuration. I, personally, do not see this as a problem.
>>
>
>

---

From: Gert Doering <[email-masked]>
Date: Tue, 7 Jan 2014 11:40:01 +0100

Hi,

>  impetuous, and send it out.  apologies for it now being a very stale rant.]

Your stale rant is completely missing the point, unfortunately.

Your multi-million-dollar enterprise can do DHCPv6-based IPv6 address 
assignment perfectly well today.  Client and server implementations
exist, and RFCs back that.

The thing that can not be done today is "do that if you do not have RAs
on your network, that will tell the clients 'go to the DHCPv6 server 
for address information, but route the packets to me'".

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Ray Hunter <[email-masked]>
Date: Tue, 07 Jan 2014 13:12:20 +0100

Lorenzo Colitti wrote:
> On Tue, Jan 7, 2014 at 12:10 PM, Matthew Petach <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> I think that's a terrible example. AFAIK (and I think I was in the 
> room) the filter-aaaa-on-v4 hack was originally proposed for use in 
> CPEs, and it met with opposition even there. Opposition for getting it 
> into bind was pretty strong, and AIUI - as you say - it was included 
> only because someone said, "We have a contract. Here's a check. Now 
> honour the contract."
>
> In hindsight, it turned out to be a really bad idea. The hack was 
> never used for its intended purpose in the CPE, but it did end up 
> being used basically by an entire country to cling to a fundamentally 
> broken IPv6 deployment model (the NTT walled-garden "here's a global 
> IPv6 address and a default route, but you can't reach the IPv6 
> Internet, have a nice day" fiasco). I think that if filter-aaaa-on-v4 
> is an example of anything, it's an example of the law of unintended 
> consequences.
>
> DHCPv6 is not *necessary* accounting and control. It is one way to do 
> it, but you can do it just as well with address tracking in the 
> switches. Address tracking is also much more flexible (allowing 
> multiple addresses, dynamic addresses) and more secure: while using 
> DHCP for address verification requires strong first-hop security in 
> the switches (DHCP snooping, address-to-MAC binding, forced 
> forwarding, etc) address tracking requires none of that. In fact, 
> there's a fallacy here: I have personally see security people think 
> that DHCP-provided addresses are secure, when by themselves they are 
> not secure at all. They can only be made secure if first-hop security 
> is in place.
>
> In fact, I'd argue that DHCPv4 is not particularly well-suited for 
> address tracking at all, and the only reason we use DHCP for address 
> tracking in IPv4 is that in IPv4 there is basically no other mechanism 
> to assign addresses.
> </sidenote>
>
> With that out of the way: why are you talking about address 
> assignment. DHCPv6-only address assignment is already a standard. Send 
> an RA with M=1 (and optionally a prefix with A=0) and - assuming your 
> hosts implement DHCPv6 - you're done.
>
> standardizing it is a much higher bar. In hindsight, I think it's 
> pretty clear to that filter-aaaa-on-v4 is a terrible idea (just think 
> of what will happen to it when DNSSEC rolls around), and I think it's 
> clear that it will never be standardized. But that doesn't stop people 
> from using it.
>
> DHCPv6-only address assignment is already possible today. But take a 
> random $FEATURE. If you're right and your multi-billion dollar 
> enterprises get all host operating systems to support $FEATURE, then 
> it will be a de facto standard. But until then, it would be a mistake 
> for the IETF to to standardize $FEATURE if there are existing and 
> technically superior ways of implmenting $FEATURE's functionality just 
> because a subset of users want to stick to the same practices they 
> used in IPv4.
>
> assignment. In fact, they saw this as an opportunity to not run a 
> DHCPv6 server at all.
>
> Cheers,
> Lorenzo
Correct me if I'm wrong, but there seems to be an underlying assumption 
in this discussion that the infra and infra people knowing the address 
that a particular host uses for communication is universally for "bad 
things"

e.g. to break privacy so people can be tracked.
e.g. to prevent unauthorised access.

There are also "good things", especially in a "dumb host/ smart network" 
model found in many enterprises

e.g. your friendly help desk and network engineering staff can trace 
your communication problem, and can correlate problem investigation 
across various logs.
e.g. you can be given VIP DSCP settings to improve your voice quality 
and for call admission purposes.
e.g. WAN acceleration can be used for certain servers/apps without 
overloading the acceleration engine.
e.g. PBR can be used to send your traffic over a better path.

Not all LANs are centrally managed. And being able to tell an outsourcer 
to add "this config per interface and it'll all work" is definitely 
preferable in some environments.
RA flags are not that tough to set, but I'm certain many will mess it up 
and the A flag will not be set to 0. Then the ability to turn off/filter 
RA altogether has some attraction.

Telling people "From now on, you have to organise your security ACLs, 
firewall rules, WAN acceleration rules, PBR, QoS ACLs per /64 LAN 
prefix" hasn't gone down too well so far.
On the long term this may be a good thing, but lack of functional 
equivalence with IPv4 is certainly a hurdle to deployment.

-- 
Regards,
RayH

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 7 Jan 2014 05:49:50 -0800 (PST)

<snip>

> e.g. to prevent unauthorised access.

I don't think so. I think there are are quite valid reasons to track addresses in use. The point is that DHCPv6 cannot possibly accurately provide that information, because it only has records of the addresses it hands out, which doesn't include other types of addresses that hosts may or will have, such as static, SLAAC or link-local addresses.

If the enterprise admin has absolute control over the hosts then it would seem to me that they don't need to be concerned with unauthorised address use, because there is no possibility of unauthorised address use. In the least, as first steps, they should be enforcing this control by using 802.1X to prevent unauthorised access to the network, as well as shutting down network ports that aren't in use.

If they are concerned about unauthorised address use, that means they don't have absolute control over the hosts and their attachment to the network, and therefore there is a possibility that untrusted and less controlled hosts can choose to not use the DHCPv6 assigned addresses, use link-locals instead for which DHCPv6 has no records, or completely ignore the DHCPv6 assigned addresses and statically configure their own ULA prefix to use instead.

So DHCPv6 isn't an effective tool to accurately track address usage because untrusted hosts can choose not to use it or can avoid using the addresses it gives out.

> equivalence with IPv4 is certainly a hurdle to deployment.

I really struggle to understand how the additional effort to have to constantly "right size" IPv4 prefixes has somehow made creating firewall rules, ACLs, PBR etc. preferable. Every time the IPv4 prefix length is changed, all of those things need to be updated. It's monotonous work, may involve after hours changes to avoid network service disruption, and requires effort and concentration to ensure it is done correctly and accurately. Some people might find that enjoyable, but I think they're well and truly in the minority (people with no experience doing it might enjoy it the first few times, but after that ...).

Actually, most enterprises now use RFC1918 addresses, and if you look at their addressing, they'll commonly pick /24s for their LAN segments and use them everywhere (and call them "Class C"s). So it seems to be human nature to try to pick a simple and single large enough prefix size from the outset when the opportunity is there to do so.

"Right sizing" IPv4 prefixes has only really been necessary to deal with IPv4's lack of public address space, and has created much additional administrative work and network service disruption. It is a cost that can easily be eliminated when the address space is large. Making the network cheaper to operate and increasing its availability by minimising configuration changes can only be a good thing.

Regards,
Mark.

---

From: Owen DeLong <[email-masked]>
Date: Tue, 7 Jan 2014 10:10:49 -0800

> will happen, with or without your agreement

We are talking about two different things…

DHCPv6-assignment-only is possible today. It is what happens if you set the M bit in the RA. DHCPv6 will then have full control of address assignment.

What is not possible today is to do that DHCPv6 assignment without receiving an RA to instruct the host to do so.

Why is that a problem for the network environments you have described?

As to getting software to do it, that’s not really the problem. The problem is that there’s already lots of deployed hardware and software that is implemented as defined in the current RFCs.

It’s the elimination of RAs that is problematic. Using DHCP exclusively for address assignment isn’t difficult. Adding routing information to DHCPv6 wouldn’t be all that difficult.

Eliminating RAs from the process would require a major change that would likely pose some level of compatibility problem with existing deployments.

Owen

---

From: Randy Bush <[email-masked]>
Date: Thu, 09 Jan 2014 06:00:07 +0900

> for address information, but route the packets to me'".

the multi-million-euro enterprise can continue to do ipv4.  and that's
what they are doing.  we can stick our heads <fill in> and pretend that
this is not a festering and embarrassing problem or we can fix it.

randy

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Jan 2014 16:05:11 -0500

> this is not a festering and embarrassing problem or we can fix it.

Okay, Randy.   You're a smart, articulate guy.   Can you tell us what is missing that we need to add, and in what sense it's missing?   I have yet to hear a clear statement of what the problem is.

---

From: Randy Bush <[email-masked]>
Date: Thu, 09 Jan 2014 06:31:34 +0900

> Okay, Randy.  You're a smart, articulate guy.  Can you tell us what is
> missing that we need to add, and in what sense it's missing?  I have
> yet to hear a clear statement of what the problem is.

then you are a newcomer to an eight year old conversation.  i will not
bother with the technical issues which have been discussed endlessly,
rinse repeat.  that's why we have list archives.

the bottom line is that the vast majority enterprises, campuses, ... are
run by IT departments which pay the bills and do it their way.  they use
dhcp, good, bad, indifferent.  we don't have to like what the people who
pay us money want to do.  arguing with the customer is generally not a
good strategy.

yes there are enterprises who drink the koolaid and follow the true
religion.  so far, they are a teensie minority.  the vast majority of
enterprises run ipv4, rfc1918, ...  when they look at ipv6 the first
question, and often the only question is "how much will it cost?"  and
the answer to that is bad enough without any speed bumps of changing
what they are doing today.

if we want them to deploy ipv6, as opposed to more rfc1918 space, then
we need to remove all speed bumps.  not discuss them.  not tell them
that RA is the true religion.  frelling remove the speed bump.

there is no harm and there is trivial cost in giving the customer what
she wants.

that the ietf has refused to do so for years is characteristic of the
arrogance and ignorance which leaves ipv6's survival still at risk.

randy

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Jan 2014 16:47:39 -0500

> that RA is the true religion.  frelling remove the speed bump.

Can you name a specific speed bump?   I've been listening to this conversation for eight years too, and have yet to hear one named.   You seem to be saying that RA is the speed bump, but that's not specific.   What is it about RA that "they" need changed?

---

From: Randy Bush <[email-masked]>
Date: Thu, 09 Jan 2014 06:57:34 +0900

> Can you name a specific speed bump?  I've been listening to this
> conversation for eight years too, and have yet to hear one named.  You
> seem to be saying that RA is the speed bump, but that's not specific.
> What is it about RA that "they" need changed?

the missing dhcp function, exit router

---

From: Jared Mauch <[email-masked]>
Date: Wed, 8 Jan 2014 17:03:07 -0500

> the missing dhcp function, exit router

For the rest of the class, please read the "turning on comcast v6" thread for the operator community feedback.

http://mailman.nanog.org/pipermail/nanog/2013-December/thread.html
http://mailman.nanog.org/pipermail/nanog/2014-January/thread.html

- Jared

---

From: joel jaeggli <[email-masked]>
Date: Wed, 08 Jan 2014 14:08:26 -0800

> there is no harm and there is trivial cost in giving the customer what

So not-withstanding my whatever personal feelings I have related to this
dicussion (which mostly involve digsust) there are real consequences for
keying up you radio and sending a dhcp request that may never be
answered every so often until the end of time... This applies in the
ipv4 case for ipv4 adhoc networks as well. but it certainly applies to
ipv4 only subnets with ipv6 speakers (not really an uncommon case), ipv6
adhoc networks, dual stack networks with no dhcpv6 (you should innore
RAs at your peril) and so on.

There's now way to get these things to shut up in ipv4 without managing
them. it would be nice if we could do better than that.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 8 Jan 2014 22:09:27 +0000

> what they are doing.

That's fine - let them leave their IPv4 network infrastructure in
place and deploy IPv6 using AERO:

http://tools.ietf.org/html/draft-templin-aerolink

It's all very simple. End user networks get IPv6 prefix delegations,
and enterprise network servers keep track of where all the end user
networks are located. DHCPv6 for prefix delegation, and RS/RA for
routing and neighbor state maintenance. The enterprise network is
seen by the end systems as a giant "link" over which IPv6 packets
are transmitted between "neighbors". That's it.

Thanks - Fred
[email-masked]

---

From: Ole Troan <[email-masked]>
Date: Wed, 8 Jan 2014 23:41:19 +0100

> http://mailman.nanog.org/pipermail/nanog/2014-January/thread.html

15 messages in, and I still don't get it.
could you summarize the problem in a sentence please?

cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Jan 2014 10:20:39 +0900

> this is not a festering and embarrassing problem or we can fix it.

We're talking about the same enterprises that weren't at the forefront of
IPv4 adoption either, right? A [deliberately caricatured] strawman
counterargument would be that what's going on is:

1. The network managers in those enterprises are change averse.
2. "We can't deploy IPv6 until we can configure routing via DHCPv6" is an
excuse for not deploying IPv6, but the real reason is that there's no
business need for doing so, and providing a way to configure routing via
DHCPv6, will just cause them to move on to the next excuse.
3. When there is a business need to deploy IPv6, it will be deployed,
lack-of-routing-in-DHCPv6 or not (after all that's what my enterprise did,
and a fair number of others too, right?)

Knock that down?

Cheers,
Lorenzo

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Jan 2014 10:45:35 +0900

> could you summarize the problem in a sentence please?

If you want to read it, it starts at
http://mailman.nanog.org/pipermail/nanog/2013-December/062933.html

The one-sentence summary is "we want to do it the same way as we do in
IPv4".

---

From: Randy Bush <[email-masked]>
Date: Thu, 09 Jan 2014 17:04:18 +0900

> The one-sentence summary is "we want to do it the same way as we do in

close.  we want the paying customer to be able to move to ipv6 with as
little cost and effort as possible.

we know this violates the one true religion.  so did getting rid of tlas
and 42 other symptoms of arrogance in ipv6.

randy

---

From: Gert Doering <[email-masked]>
Date: Thu, 9 Jan 2014 09:15:45 +0100

Hi,

> this is not a festering and embarrassing problem or we can fix it.

The problem statement given for the "multi-million-euro enterprise" was 
"they want to use DHCPv6!!!!"  (not "DHCPv6 without RA").

And they *can*.

Gert Doering
        -- NetMaster

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Jan 2014 19:05:49 +0900

> and 42 other symptoms of arrogance in ipv6.

I think the reason that people feel so strongly about it is that they feel
that we as a community can do better than that, and that if we don't strive
to do better than that now, the cumulative effect of operational
familiarity with the old system, lack of developer familiarity, and buggy
implementations  will make it so that the new system cannot be made any
better than the old.

Also, TLAs were a fundamental change to the model. It wouldn't have worked.
By comparison, not having routing in DHCPv6 is trivial, and we know that it
works (even in enterprises).

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 9 Jan 2014 02:06:33 -0800 (PST)

----- Original Message -----
> From: Randy Bush <[email-masked]>
> To: Ted Lemon <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Sent: Thursday, 9 January 2014 8:57 AM
> Subject: Re: [v6ops] New Version Notification for    draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)
> 

I don't think this is really true at all. What motivates an enterprise to deploy a new technology is primarily what it does for the enterprise, not specific features of it. 

In the early 1990s, enterprises didn't deploy IPX for IPX's sake. They didn't say, "We want IPX." They said, "We want to be able to share files and printers, because it is cheaper than floppy disks and sneakernet, and buying everybody individual printers." If they chose Novell Netware to share files and printers, they then deployed IPX because Novell Netware required it. Those who chose Banyan Vines for file and print sharing deployed the Banyan Vines protocol instead.

In the middle to late 1990s, enterprises didn't deploy IPv4 for IPv4's sake.  They didn't say, "We want IPv4." They said, "We want to be able to email other organisations and be able to access the WWW, because we can email customers and suppliers more quickly than using slower fax and snail mail, and access information useful to our business on the Internet." They then needed IPv4 to do that, so they deployed IPv4 (and wondered why it all had to be so hard with address classes, subnet masks and default gateways, compared to deploying and operating turn-key IPX.)

For most enterprises, other than those that make their money from information technology (like the ones that most people on this mailing list work for), technology is a "necessary evil" to support their actual business of making some other type of widget. It is a cost that takes away from the larger profit they could make on their widgets. If they can reduce those costs, or even eliminate them, they will, because that increases their widget profit. 

So a new technology has to either save the enterprise money or make the enterprise money for it to be justified.

The "killer app" for IPv6 for an enterprise is one that exclusively operates over IPv6 (instead of over their already deployed IPv4) _and_ makes or saves them money. Some enterprises may never encounter an IPv6-only application that does this, so they may never have an incentive to deploy it on their network. They may wish to have access to the IPv6 Internet eventually, but all that might mean is IPv6 enabling the external interface of their corporate policy enforcing web proxy, reached over RFC1918 IPv4.

Change IPv6 as much as people want, but if it isn't possible to identify how it, or the applications that exclusively run over it will save or make them money, enterprises will ignore it. More change and more options to it will only increase it's deployment costs, further increasing the barrier it has to jump before it saves or makes an enterprise money. 

Regards,
Mark.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Jan 2014 19:10:30 +0900

On Thu, Jan 9, 2014 at 7:06 PM, Mark ZZZ Smith <[email-masked]>wrote:

> Change IPv6 as much as people want, but if it isn't possible to identify
> how it, or the applications that exclusively run over it will save or make
> them money, enterprises will ignore it. More change and more options to it
> will only increase it's deployment costs, further increasing the barrier it
> has to jump before it saves or makes an enterprise money.
>

Hear, hear.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 9 Jan 2014 16:55:04 +0000

Hi Mark,

In our enterprise we are seeing an emerging network-layer "killer app"
for IPv6; namely, the deployment of mobile multi-access end user devices
that need to maintain a stable IP address or subnet. These devices are
commonly tablets or handsets of various manufacturers that have wireless
access technologies that get (re)assigned different access addresses as
they move around, and so tunneling is needed to maintain stable end-user
addresses.

As the number of mobile devices grows, the end user addresses assigned
to mobiles would soon exhaust and fragment the RFC1918 space - hence the
need for IPv6. But, we only see a need to deploy IPv6 on the mobiles
themselves and we do not necessarily see a need to upgrade the entire
enterprise routing structure to IPv6.

Think of the tablet/handset as a miniature "mobile router" - a device
that should be able to connect up its own applications plus any number
of additional end user devices (Internet connection sharing). The mobile
router gets an IPv6 prefix (/64 or shorter), and a routing system inside
the enterprise network tracks the mobiles as they move around. What I am
describing is AERO:

Thanks - Fred

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Mark ZZZ Smith
> Sent: Thursday, January 09, 2014 2:07 AM
> To: Randy Bush; Ted Lemon
> Cc: [email-masked]
> Subject: [v6ops] Enterprises won't deploy IPv6 for IPv6's sake (as they didn't IPv4, IPX, XNS, or
> DECNet)
> I don't think this is really true at all. What motivates an enterprise to deploy a new technology is
> primarily what it does for the enterprise, not specific features of it.
> 
> In the early 1990s, enterprises didn't deploy IPX for IPX's sake. They didn't say, "We want IPX." They
> said, "We want to be able to share files and printers, because it is cheaper than floppy disks and
> sneakernet, and buying everybody individual printers." If they chose Novell Netware to share files and
> printers, they then deployed IPX because Novell Netware required it. Those who chose Banyan Vines for
> file and print sharing deployed the Banyan Vines protocol instead.
> 
> In the middle to late 1990s, enterprises didn't deploy IPv4 for IPv4's sake.  They didn't say, "We
> want IPv4." They said, "We want to be able to email other organisations and be able to access the WWW,
> because we can email customers and suppliers more quickly than using slower fax and snail mail, and
> access information useful to our business on the Internet." They then needed IPv4 to do that, so they
> deployed IPv4 (and wondered why it all had to be so hard with address classes, subnet masks and
> default gateways, compared to deploying and operating turn-key IPX.)
> 
> For most enterprises, other than those that make their money from information technology (like the
> ones that most people on this mailing list work for), technology is a "necessary evil" to support
> their actual business of making some other type of widget. It is a cost that takes away from the
> larger profit they could make on their widgets. If they can reduce those costs, or even eliminate
> them, they will, because that increases their widget profit.
> 
> The "killer app" for IPv6 for an enterprise is one that exclusively operates over IPv6 (instead of
> over their already deployed IPv4) _and_ makes or saves them money. Some enterprises may never
> encounter an IPv6-only application that does this, so they may never have an incentive to deploy it on
> their network. They may wish to have access to the IPv6 Internet eventually, but all that might mean
> is IPv6 enabling the external interface of their corporate policy enforcing web proxy, reached over
> RFC1918 IPv4.
> 
> Change IPv6 as much as people want, but if it isn't possible to identify how it, or the applications
> that exclusively run over it will save or make them money, enterprises will ignore it. More change and
> more options to it will only increase it's deployment costs, further increasing the barrier it has to
> jump before it saves or makes an enterprise money.
> 
> 
> Regards,
> Mark.

---

From: Tim Chown <[email-masked]>
Date: Thu, 9 Jan 2014 17:04:59 +0000

Hi,

> enterprise routing structure to IPv6.

The campus wireless solutions I've seen from vendors to date that support IPv6 do some "interesting" things to support devices roaming between IPv6 wireless subnets.  They certainly don't seem to use MIPv6, rather it seems common to use either unicast RAs and/or L2 tunnelling between controllers. e.g. see http://www.cisco.com/en/US/products/ps10315/products_tech_note09186a0080bae506.shtml#mobility.

Tim

---

From: Tim Chown <[email-masked]>
Date: Thu, 9 Jan 2014 17:12:24 +0000

> arrogance and ignorance which leaves ipv6's survival still at risk.

I was reminded of this paper in another discussion recently.

http://groups.csail.mit.edu/ana/Publications/PubPDFs/Tussle2002.pdf

It could be argued there's a tussle here...

Tim

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 9 Jan 2014 17:21:41 +0000

Hi Tim,

> The campus wireless solutions I've seen from vendors to date that
> support IPv6 do some "interesting" things to support devices roaming
> between IPv6 wireless subnets.  They certainly don't seem to use
> MIPv6, rather it seems common to use either unicast RAs and/or L2
> tunnelling between controllers. e.g. see

http://www.cisco.com/en/US/products/ps10315/products_tech_note09186a0080bae506.shtml#mobility.

I am thinking of mobiles that have WiFi plus 3G/4G. When the mobile is
in proximity of my enterprise infrastructure then it can certainly be
managed as it hops between WLCs as you suggest. But, when the mobile
leaves the campus and goes in via a Starbucks WiFi (or maybe my home
WiFi) it is beyond the management realm of the enterprise and has to
do something if it wants to maintain a stable IP address/subnet. Or,
if the mobile goes off the "WiFi grid" it has to fire up its 3G/4G
link and then still somehow maintain stability.

This is not about MIPv6 - it is about AERO:

Thanks - Fred

PS I shouldn't have to ask, but please keep this as plaintext instead
   of converting to something else.

---

From: Tim Chown <[email-masked]>
Date: Thu, 9 Jan 2014 17:23:48 +0000

> link and then still somehow maintain stability.

MPTCP?  A la Siri on iOS7 etc :)

> This is not about MIPv6 - it is about AERO:

Well, the thread is about something else, so back to that....

Tim

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 9 Jan 2014 17:28:50 +0000

Hi Tim,

> From: Tim Chown [mailto:[email-masked]]
> Sent: Thursday, January 09, 2014 9:24 AM
> To: Templin, Fred L
> Cc: Mark ZZZ Smith; Randy Bush; Ted Lemon; [email-masked]
> Subject: Re: [v6ops] Enterprises won't deploy IPv6 for IPv6's sake (as they didn't IPv4, IPX, XNS, or
> DECNet)
> 
> 

That won't get me to a mobile router - it only addresses the apps
on the mobile itself. 
 
> Well, the thread is about something else, so back to that....

The thread is about IPv6 deployment in enterprise networks. AERO is
about IPv6 deployment in enterprise networks (which should also be
taken as input to your IPv6 enterprise deployment doc).

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 9 Jan 2014 17:36:21 +0000

> That won't get me to a mobile router - it only addresses the apps

Should also say, I want my corporate assets to have a stable address
in the DNS that doesn't change even if the assets are mobile and
frequently changing their network point of attachment.

Thanks - Fred

---

From: joel jaeggli <[email-masked]>
Date: Thu, 09 Jan 2014 10:50:19 -0800

> frequently changing their network point of attachment.

As a consumer, the mechanic by which my connectivity to my assets is
rendered seamless is irrelevant, it's the doing it part that's important.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 9 Jan 2014 20:27:54 +0000

Hi Joel,

> From: joel jaeggli [mailto:[email-masked]]
> Sent: Thursday, January 09, 2014 10:50 AM
> To: Templin, Fred L; Tim Chown
> Cc: [email-masked]

What AERO is suggesting is mobile networks that retain the same IPv6
addresses/prefixes wherever they happen to move to. So, if my tablet
is a mobile router that serves all of my other personal networked
devices for example, those devices all get stable IPv6 addresses.
Or, if maybe my airplane is a mobile router that changes its network
point of attachment frequently as it travels across continents, the
airline should still be able to address the airplane and all of its
addressable components.

I guess you are asking whether we need IPv6 routing and addressing
all the way out to the end systems or whether just getting to some
sort of middlebox "concentrator" is sufficient. I think that comes
down to whether we truly want IPv6 end-to-end.

Thanks - Fred

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Jan 2014 10:17:40 +0100

Le 09/01/2014 18:28, Templin, Fred L a écrit :
> Hi Tim,
>
>> -----Original Message----- From: Tim Chown
>> [mailto:[email-masked]] Sent: Thursday, January 09, 2014 9:24
>> AM To: Templin, Fred L Cc: Mark ZZZ Smith; Randy Bush; Ted Lemon;
>> [email-masked] Subject: Re: [v6ops] Enterprises won't deploy IPv6
>> for IPv6's sake (as they didn't IPv4, IPX, XNS, or DECNet)
>>
>>
>>>> The campus wireless solutions I've seen from vendors to date
>>>> that support IPv6 do some "interesting" things to support
>>>> devices roaming between IPv6 wireless subnets.  They certainly
>>>> don't seem to use MIPv6, rather it seems common to use either
>>>> unicast RAs and/or L2 tunnelling between controllers. e.g. see
>>>
>>> in proximity of my enterprise infrastructure then it can
>>> certainly be managed as it hops between WLCs as you suggest. But,
>>> when the mobile leaves the campus and goes in via a Starbucks
>>> WiFi (or maybe my home WiFi) it is beyond the management realm of
>>> the enterprise and has to do something if it wants to maintain a
>>> stable IP address/subnet. Or, if the mobile goes off the "WiFi
>>> grid" it has to fire up its 3G/4G link and then still somehow
>>> maintain stability.
>>
> That won't get me to a mobile router - it only addresses the apps on
> the mobile itself.

YEs, and only apps using a particular transport protocols, not all.

(and yes the news of MPTCP at Apple is encouraging about that
  particular protocol).

> taken as input to your IPv6 enterprise deployment doc).

Right.  But since this thread relates to the DHCP discussion, would AERO
have an aspect related to DHCP?  Or to RA?  How would an AERO
Router self-configure its address, its mobile network prefix and its
default route?  Would it accept many combinations or just one?

Alex

>
> Thanks - Fred [email-masked]
>
>> Tim
>>
>>>
>>> Thanks - Fred [email-masked]
>>>
>>> PS I shouldn't have to ask, but please keep this as plaintext
>>> instead of converting to something else.
>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 10 Jan 2014 16:00:56 +0000

Hi Alex,

> From: v6ops [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
> Sent: Friday, January 10, 2014 1:18 AM
> To: [email-masked]

AERO certainly has aspects related to both DHCP and RA. AERO nodes are
all routers (not hosts) and so they would use DHCP as requesting routers
for Prefix Delegation but not for address configuration. And, they would
use unicast RS/RA for neighbor cache and default route maintenance to
their default router.

AERO nodes self-configure link-local addresses through the AERO address
format specified in the document. AERO nodes only assign link-local
addresses to their AERO interfaces; they do not assign addresses of
other scopes. AERO nodes connect IPv6 end user networks to the AERO
link, and use the AERO link only as transit to get to other IPv6
networks. AERO nodes use unicast IPv6 ND for neighbor cache
maintenance and route optimization.

That is it in a nutshell. Reading and understanding this is enough
basis for understanding the document as a whole.

Thanks - Fred

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Jan 2014 17:18:27 +0100

Le 10/01/2014 17:00, Templin, Fred L a écrit :
> Hi Alex,
>
>> -----Original Message----- From: v6ops
>> [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
>> Sent: Friday, January 10, 2014 1:18 AM To: [email-masked] Subject:
>> Re: [v6ops] Enterprises won't deploy IPv6 for IPv6's sake (as they
>> didn't IPv4, IPX, XNS, or DECNet)
>>
>>>> [mailto:[email-masked]] Sent: Thursday, January 09, 2014
>>>> 9:24 AM To: Templin, Fred L Cc: Mark ZZZ Smith; Randy Bush; Ted
>>>> Lemon; [email-masked] Subject: Re: [v6ops] Enterprises won't
>>>> deploy IPv6 for IPv6's sake (as they didn't IPv4, IPX, XNS, or
>>>> DECNet)
>>>>
>>>>
>>>>>> The campus wireless solutions I've seen from vendors to
>>>>>> date that support IPv6 do some "interesting" things to
>>>>>> support devices roaming between IPv6 wireless subnets.
>>>>>> They certainly don't seem to use MIPv6, rather it seems
>>>>>> common to use either unicast RAs and/or L2 tunnelling
>>>>>> between controllers. e.g. see
>>>>>
>>>>> certainly be managed as it hops between WLCs as you suggest.
>>>>> But, when the mobile leaves the campus and goes in via a
>>>>> Starbucks WiFi (or maybe my home WiFi) it is beyond the
>>>>> management realm of the enterprise and has to do something if
>>>>> it wants to maintain a stable IP address/subnet. Or, if the
>>>>> mobile goes off the "WiFi grid" it has to fire up its 3G/4G
>>> The thread is about IPv6 deployment in enterprise networks. AERO
>>> is about IPv6 deployment in enterprise networks (which should
>>> also be taken as input to your IPv6 enterprise deployment doc).
>>
>> Right.  But since this thread relates to the DHCP discussion, would
>> AERO have an aspect related to DHCP?  Or to RA?  How would an AERO
>> Router self-configure its address, its mobile network prefix and
>> its default route?  Would it accept many combinations or just one?
>
> AERO certainly has aspects related to both DHCP and RA. AERO nodes
> are all routers (not hosts) and so they would use DHCP as requesting
> routers for Prefix Delegation but not for address configuration. And,
> they would use unicast RS/RA for neighbor cache and default route
> maintenance to their default router.

All while I understand what is said above, I wonder whether running two
protocols simultaneously on slow AERO links is maybe little optimal, or not.

Alex

>
> AERO nodes self-configure link-local addresses through the AERO
> address format specified in the document. AERO nodes only assign
> link-local addresses to their AERO interfaces; they do not assign
> addresses of other scopes. AERO nodes connect IPv6 end user networks
> to the AERO link, and use the AERO link only as transit to get to
> other IPv6 networks. AERO nodes use unicast IPv6 ND for neighbor
> cache maintenance and route optimization.
>
>>>>> PS I shouldn't have to ask, but please keep this as
>>>>> plaintext instead of converting to something else.
>>>
>>> _______________________________________________ v6ops mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>>
>>
>>

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 10 Jan 2014 16:37:46 +0000

Hi Alex,

> protocols simultaneously on slow AERO links is maybe little optimal, or not.

I will give you that the AERO document is currently using RS/RA
primarily because "it's there". For AERO, there is nothing magical
about RS/RA that could not also be accommodated by NS/NA. But, we
will certainly want DHCP-PD.

Thanks - Fred

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 11 Jan 2014 11:31:03 +0100

Fred,

Thanks for the message.

Le 10/01/2014 17:37, Templin, Fred L a écrit :
> Hi Alex,
>
>>>> Right.  But since this thread relates to the DHCP discussion,
>>>> would AERO have an aspect related to DHCP?  Or to RA?  How
>>>> would an AERO Router self-configure its address, its mobile
>>>> network prefix and its default route?  Would it accept many
>>>> combinations or just one?
>>>
>>> AERO certainly has aspects related to both DHCP and RA. AERO
>>> nodes are all routers (not hosts) and so they would use DHCP as
>>> requesting routers for Prefix Delegation but not for address
>>> configuration. And, they would use unicast RS/RA for neighbor
>>> cache and default route maintenance to their default router.
>>
>> All while I understand what is said above, I wonder whether
>> running two protocols simultaneously on slow AERO links is maybe
>> little optimal, or not.
>
> primarily because "it's there".

I think that is very good and should be used.  I think there are many
IPv6 deployments where RS/RA are there and should be used.  I also use
it whenever it's there and I would like it to.

However, let me try to suggest an alternative perspective for other
kinds of work.

There are a number of networks which are not there, but which need to
design and plan.  Their goal is not to satisfy some IETF discussion, but
to satisfy some professional need.  E.g. a new large building of offices
needs to connect to the Internet, or a new highway IP network needs to
be deployed.

When planning this, in the environment where I live, very often the
absolute requirement is to do IPv4 first, and keep IPv6 in mind, prepare
for it, be ready for IPv6 in maybe 2-7 years.

That is the topmost and absolute requirement, can't change.

This is a different approach than deploying IPv6 in an Enterprise on top
of IPv4 already there, or the requirement where one builds a new IP
network from scratch and make it IPv6 native and only.

Given that, one wants to make it first IPv4 (IPv4 innovation is still
needed in some protcols), and plan for as little effort as possible to
deploy to IPv6.  I.e. make them as much as possible look the same.  If
not, there is additional software effort, additional money to look for,
additional time to add to end of project.

> For AERO, there is nothing magical about RS/RA that could not also
> be accommodated by NS/NA. But, we will certainly want DHCP-PD.

Ok.

Alex

>>>  link-local addresses to their AERO interfaces; they do not
>>> assign addresses of other scopes. AERO nodes connect IPv6 end
>>> user networks to the AERO link, and use the AERO link only as
>>> transit to get to other IPv6 networks. AERO nodes use unicast
>>> IPv6 ND for neighbor cache maintenance and route optimization.
>
>
>

---

From: Mark ZZZ Smith <[email-masked]>
Date: Sat, 11 Jan 2014 16:10:33 -0800 (PST)

----- Original Message -----
> From: Alexandru Petrescu <[email-masked]>
> To: "Templin, Fred L" <[email-masked]>; "[email-masked]" <[email-masked]>
> Cc: 
> Sent: Saturday, 11 January 2014 9:31 PM
> Subject: Re: [v6ops] Enterprises won't deploy IPv6 for IPv6's sake (as they didn't IPv4, IPX, XNS, or DECNet)
> 
> Fred,
> 
> Thanks for the message.
> 

<snip>

> additional time to add to end of project.

So let's imagine IPv6 was just IPv4 with bigger addresses, nothing else changed, which is what I think you're saying some people think it should have been. How would deploying IPv4 with bigger addresses, in addition to IPv4 with small addresses, save or make an enterprise money today or in the near future?

To pick a hypothetical example, imagine a golf club manufacturer. How would deploying IPv6 (of either IPv4 + bigger addresses, or what we have today) decrease the cost of manufacturing golf clubs, or increase the sales of golf clubs? I can't think of how IPv6 would decrease their manufacturing costs, and I don't think a "We've got an IPv6 network" sticker on the box will increase golf club sales significantly (they might sell a extra few hundred to network engineers, but that would be it).

In the views of some, if IPv6 had just been IPv4 with bigger addresses it might slightly improve the business case to deploy it, because it would have been less to learn, and therefore theoretically less cost to operate. Lower costs are great, but less costs don't matter if you don't need what the technology provides.

I used the following in another off-list email about this topic, I think it is worth posting here:

"I once read that when you go to the hardware store to buy a drill, what you're really buying is a hole. The drill is the means, the hole is the end.

No matter how fancy the drill is, there will be some people who don't need a hole, and therefore will never buy a drill. That's not a statement of the success or failure of the drill to make holes, and nor will adding further features and enhancements to the drill increase the demand for holes.

So IPv6 is the means, and an IPv6-only application, or an IPv6 application that works much better than an IPv4 one, is the end. It is only when enterprises (and others) want the IPv6 end will they then be prepared to deploy the IPv6 means."

If people want to stimulate IPv6 adoption in enterprises, then it would seem to me that the focus needs to be on developing or demonstrating the value of either moving applications to using IPv6 instead of IPv4, or creating applications that cannot or cannot easily be operated over IPv4. While I don't know if it is used much, one example of such an application is Apple's Back to My Mac service, described in RFC6281.

Regards,
Mark.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 13 Jan 2014 16:25:04 +0000

Hi Mark,

> From: Mark ZZZ Smith [mailto:[email-masked]]
> Sent: Saturday, January 11, 2014 4:11 PM
> To: Alexandru Petrescu; Templin, Fred L; [email-masked]
> So let's imagine IPv6 was just IPv4 with bigger addresses, nothing else changed, which is what I think
> you're saying some people think it should have been. How would deploying IPv4 with bigger addresses,
> in addition to IPv4 with small addresses, save or make an enterprise money today or in the near
> future?
> 
> To pick a hypothetical example, imagine a golf club manufacturer. How would deploying IPv6 (of either
> IPv4 + bigger addresses, or what we have today) decrease the cost of manufacturing golf clubs, or
> increase the sales of golf clubs? I can't think of how IPv6 would decrease their manufacturing costs,
> and I don't think a "We've got an IPv6 network" sticker on the box will increase golf club sales
> significantly (they might sell a extra few hundred to network engineers, but that would be it).
> 
> In the views of some, if IPv6 had just been IPv4 with bigger addresses it might slightly improve the
> business case to deploy it, because it would have been less to learn, and therefore theoretically less
> cost to operate. Lower costs are great, but less costs don't matter if you don't need what the
> technology provides.
> 
> "I once read that when you go to the hardware store to buy a drill, what you're really buying is a
> hole. The drill is the means, the hole is the end.
> 
> No matter how fancy the drill is, there will be some people who don't need a hole, and therefore will
> never buy a drill. That's not a statement of the success or failure of the drill to make holes, and
> nor will adding further features and enhancements to the drill increase the demand for holes.
> 
> So IPv6 is the means, and an IPv6-only application, or an IPv6 application that works much better than
> an IPv4 one, is the end. It is only when enterprises (and others) want the IPv6 end will they then be
> prepared to deploy the IPv6 means."
> 
> 
> 
> If people want to stimulate IPv6 adoption in enterprises, then it would seem to me that the focus
> needs to be on developing or demonstrating the value of either moving applications to using IPv6
> instead of IPv4, or creating applications that cannot or cannot easily be operated over IPv4. While I
> don't know if it is used much, one example of such an application is Apple's Back to My Mac service,
> described in RFC6281.

There are "killer apps" for IPv6 and they are here today. One "app" is
mobility management of mobile networks. A second is numbering of large
scale virtual networks that may at some point need to connect up to the
physical enterprise network. Nothing in existing enterprise networks
needs to change to accommodate this, but future growth in mobile and
virtual nodes will require IPv6.

Thanks - Fred