Subject: Re: [fun] HOMENET working group proposal

From: Jari Arkko <[email-masked]>
Date: Thu, 30 Jun 2011 11:31:57 +0200

Fernando,

First off, I'm switching the reply headers to [email-masked] now, deleting 
the old homegate list from this discussion.

Secondly, I would like to explain the motivation behind focusing this 
work on IPv6. Its not so much about IPv6 being different (though I hope 
it is in some respects). The reason why I want this working group to 
focus on IPv6 is that I don't think new IETF work would have much effect 
on IPv4 home network architecture. Whereas I think we have a good chance 
of having an effect in the IPv6 case, given that there is not much 
deployed base yet in home routers, consumer ISPs, etc.

Finally, I don't think we need to take a black-and-white approach to 
discussing the end-to-end model. Obviously we know about the V6OPS 
simple security work. Of course there are firewalls in IPv6, restricting 
incoming traffic. That being said, I think the right architecture for 
IPv6 home networks is that incoming traffic is restricted *by policy* on 
a per-need basis, not by an addressing design that forever prevents us 
from allowing specific incoming protocols. This is what we mean by 
architecture specification from this working group. Practical network 
design that does the right thing and lets people do what they want -- 
not a requirement to open your network up for anything.

Jari

Fernando Gont kirjoitti:
> Hi, Jari,
>
> My high level comment/question is: the proposed charter seems to stress
> that IPv6 is the driver behind this potential wg effort... however, Ie
> think that this deserves more discussion -- it's not clear to me why/how
> typical IPv6 home networks would be much different from their IPv4
> counterparts.
>
> Bellow you'll find some comments/questions about the proposed charter.
> They are not an argument against or in favour of the creation of the
> aforementioned wg, but rather comments and/or requests for clarification...
>
> On 06/29/2011 05:47 AM, Jari Arkko wrote:
> [....]
>   
>> o Service providers are deploying IPv6, and support for IPv6 is
>> increasingly available in home gateway devices. While IPv6 resembles
>> IPv4 in many ways, it changes address allocation principles and allows
>> direct IP addressability and routing to devices in the home from the
>> Internet. This is a promising area in IPv6 that has proved challenging
>> in IPv4 with the proliferation of NAT.
>>     
>
> NAT devices involve two related but different issues:
> * address translation
> * an implicit "allow only return traffic" firewall-like functionality
>
> One would hope/expect that the former will be gone with IPv6. However, I
> don't think the latter will. As a result, even when you could "address"
> nodes that belong to the "home network", you probably won't be able to
> get your packets to them, unless those nodes initiated the communication
> instance.
>
> For instance (and of the top of my head), this functionality is even
> proposed in the "simple security" requirements that had been produced by
> v6ops.
>
>
>   
>> o End-to-end communication is both an opportunity and a concern as it
>> enables new applications but also exposes nodes in the internal
>> networks to receipt of unwanted traffic from the Internet. Firewalls
>> that restrict incoming connections may be used to prevent exposure,
>> however, this reduces the efficacy of end-to-end connectivity that
>> IPv6 has the potential to restore.
>>     
>
> I personally consider this property of "end-to-end connectivity" as
> "gone". -- among other reasons, because it would require a change of
> mindset. I'm more of the idea that people will replicate the
> architecture of their IPv4 networks with IPv6, in which end-systems are
> not reachable from the public Internet.
>
> Thanks!
>

---

From: Jari Arkko <[email-masked]>
Date: Thu, 30 Jun 2011 11:38:31 +0200

Fernando,

> My point was that, except for the mechanism for PD, I don't see a
> substantial difference here that would e.g. prevent this from being
> developed for IPv4 (in addition to IPv6). -- Yes, I know we need to
> deploy IPv6... but I don't think you can expect people to get rid of
> their *working* IPv4 devices... (i.e., not sure why any of this
> functionality should be v6-only)
>   

You have to separate IETF specifications and functionality of real-world 
products. Obviously everyone is going to have IPv4 based home networks 
for a long time.

But their architecture is largely done and cannot be easily affected. 
Vendors are now looking into adding IPv6 into their home routers and 
other devices. I want to be able to show them how to do it right. They 
can, of course, replicate everything exactly as in IPv4. Much of it is 
right, of course, but on some areas I think we can do better. This is 
why the working group should focus on IPv6. If the group is successful, 
IPv4 network design continues to be what it is, but our recommendations 
for the IPv6 network design are adopted by vendors' home devices.

Jari

---

From: Fernando Gont <[email-masked]>
Date: Thu, 30 Jun 2011 06:47:29 -0300

Jari,

On 06/30/2011 06:38 AM, Jari Arkko wrote:
> why the working group should focus on IPv6. 

My point is: Will implementation of the produced RFCs lead to home
networks in which stuff works for IPv6 differently from how it works for
IPv4? e.g., your home network would have multiple subnets (thanks to
PD), but a single IPv4 subnet?

If our work focuses only on IPv6, I get the impression that we're
heading in that direction.

If HOMENET is going to improve stuff that we already do with IPv4 (by
leveraging IPv6), then that's fine... but not what I read from this
discussion and the proposed charter.

Thoughts?

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Mark Townsley <[email-masked]>
Date: Thu, 30 Jun 2011 11:57:06 +0200

I think the consensus we had in the past BoFs and discussion in and around this topic can be summed up as stating that homenet deliverables will:

- coexist with (existing) IPv4 protocols, devices, applications, etc.
- operate in a (future) IPv6-only home network in the absence of IPv4
- be IP-agnostic whenever possible

In other words, anything we do for the IPv6 homenet cannot actively break what's already running on IPv4. Also, trying to define what the IPv4 home network should be has long reached a point of diminishing returns given the effort in doing so coupled with our ability to significantly affect what's already deployed. There's still hope we can help direct IPv6, as such that is homenet's primary focus.  However, when we can define something that is needed for IPv6 in a way that is also useful for IPv4 without making significant concessions, we should go ahead and do so. 

- Mark

On Jun 30, 2011, at 9:25 AM, Mikael Abrahamsson wrote:

> On Thu, 30 Jun 2011, Fernando Gont wrote:
> 
>> My point was that, except for the mechanism for PD, I don't see a substantial difference here that would e.g. prevent this from being developed for IPv4 (in addition to IPv6). -- Yes, I know we need to deploy IPv6... but I don't think you can expect people to get rid of their *working* IPv4 devices... (i.e., not sure why any of this functionality should be v6-only)
> 
> Chaining NAT boxes already work. I also feel that we shouldn't put in a lot of work to develop IPv4 further, that focus should be put on IPv6.
> 
>> I think this deserves a problem statement that clearly describes what we expect to be able to do (but currently can't), etc. And, if this is meant to be v6-only, state why v4 is excluded -- unless we're happy to have people connect their IPv4-devices, and see that they cannot communicate anymore.
> 
> IPv4 should be excluded because it's a dead end, and we all know it. We're just disagreeing when it's going to die and how.
> 
> -- 
> Mikael Abrahamsson    email: [email-masked]
> _______________________________________________
> homegate mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homegate

---

From: Jari Arkko <[email-masked]>
Date: Thu, 30 Jun 2011 12:02:53 +0200

Fernando,

> IPv4? 

That is the plan. And when I say "differently", I mean differences such as

* prefix delegation
* global addresses and firewalls instead of private addresses and NATs
* across-subnet communication internally in the home can be routed, not 
NATted

> e.g., your home network would have multiple subnets (thanks to

But the examples you cite are not differences we are really aiming at. 
Multiple subnets is something that generally should be avoided where 
possible, but cannot be completely avoided. It applies to IPv4 and IPv6 
in equal manner, e.g., when you have a Guest and Private SSIDs on your 
wireless. In this case the difference between IPv4 and IPv6 is merely 
that in one case we NAT to the Internet and between the two networks, in 
another case we route/firewall.

> discussion and the proposed charter.

My point is that I don't think we can change the IPv4 situation. We can 
affect the way IPv6 is used. Maybe we can even make things better in 
IPv6 than they were in IPv4. So in the end the user experience may 
improve for people who use IPv6, but it is definitely not our goal to 
improve IPv4.

Jari

---

From: Fernando Gont <[email-masked]>
Date: Thu, 30 Jun 2011 07:40:17 -0300

Hi, Mark (and Jari),

Thanks so much for your clarification! All my questions/comments have
been addressed.

Thanks,
Fernando

On 06/30/2011 06:57 AM, Mark Townsley wrote:
> 
> I think the consensus we had in the past BoFs and discussion in and
> around this topic can be summed up as stating that homenet
> deliverables will:
> 
> - coexist with (existing) IPv4 protocols, devices, applications,
> etc. - operate in a (future) IPv6-only home network in the absence of
> IPv4 - be IP-agnostic whenever possible
> 
> In other words, anything we do for the IPv6 homenet cannot actively
> break what's already running on IPv4. Also, trying to define what the
> IPv4 home network should be has long reached a point of diminishing
> returns given the effort in doing so coupled with our ability to
> significantly affect what's already deployed. There's still hope we
> can help direct IPv6, as such that is homenet's primary focus.
> However, when we can define something that is needed for IPv6 in a
> way that is also useful for IPv4 without making significant
> concessions, we should go ahead and do so.
> 
> - Mark
> 
> 
> 
>>> substantial difference here that would e.g. prevent this from
>>> being developed for IPv4 (in addition to IPv6). -- Yes, I know we
>>> need to deploy IPv6... but I don't think you can expect people to
>>> get rid of their *working* IPv4 devices... (i.e., not sure why
>>> any of this functionality should be v6-only)
>> 
>> Chaining NAT boxes already work. I also feel that we shouldn't put
>> in a lot of work to develop IPv4 further, that focus should be put
>> on IPv6.
>> 
>>> I think this deserves a problem statement that clearly describes
>>> what we expect to be able to do (but currently can't), etc. And,
>>> if this is meant to be v6-only, state why v4 is excluded --
>>> unless we're happy to have people connect their IPv4-devices, and
>>> see that they cannot communicate anymore.
>> 
>> IPv4 should be excluded because it's a dead end, and we all know
>> it. We're just disagreeing when it's going to die and how.
>> 
>> -- Mikael Abrahamsson    email: [email-masked] 
>> _______________________________________________ homegate mailing
>> list [email-masked] 
> _______________________________________________ homegate mailing
> list [email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 30 Jun 2011 12:53:25 +0200

> * across-subnet communication internally in the home can be routed,
not

[Pascal] I'd add to that multiple virtual topologies, and heterogeneous
subnets where even the link layer is not consistent across the subnet.

Automation and command/control already uses wireless technologies that
are non WIFI; ISA100.15 already works on backhaul technologies; the IETF
is missing a clear model to explain them how we isolate flows and merge
heterogeneous links into one subnet. 

I think there is a lot this group can do to pursue / extend what was
done at 6LoWPAN (ND, backbone router) so that the work there connects to
the rest of the home, and by extension, the rest of other networks such
as building and industrial plants.

Cheers,

Pascal

---

From: Fernando Gont <[email-masked]>
Date: Thu, 30 Jun 2011 09:50:02 -0300

On 06/30/2011 09:21 AM, Keith Moore wrote:

> nothing says that some results of the work can't also apply to IPv4.
> but people are far too mired in outdated assumptions today, such as
> the idea that every network needs a NAT or a firewall that filters
> based on IP addresses and ports.

I did not even argue about ports or addressing, but rather about who
initiated the communication instance.

>> If HOMENET is going to improve stuff that we already do with IPv4
>> (by leveraging IPv6), then that's fine...
> 
> no, that's not fine.   that's painting ourselves (and the Internet)
> into a corner.

I was mostly referring to not breaking what already works with v4 (i.e.,
not be a MUST for all devices in a home network to support some v6
feature for the network to work, such that our existing v4-only devices
can co-exist in whatever v6 home-network architecture we envision).

Thanks,

---

From: "Stephen [kiwin] PALM" <[email-masked]>
Date: Thu, 30 Jun 2011 07:41:21 -0700

Agreed. I would phrase it this way:
How to do IPv6 in an IPv4 world.

Some points from the Description:
  > increasingly available in home gateway devices.

This is only *part* of the story.  *Users* have lots of IPv4
devices in their home.

  > o service discovery
This is already well handled by UPnP/DLNA

  > o managing routing

There were several snippets regarding routing/subnets/heterogeneous networking
technologies.  There is already work proceeding in IEEE P1905.1
to address issues related to multiple network technologies
via a MAC/PHY Abstraction Layer.  Also there are applications today
that expect a single subnet, so new architectures should not preclude
existing applications.

regards, kiwin

On 6/29/2011 11:51 PM, Fernando Gont wrote:
> On 06/30/2011 02:12 AM, Mikael Abrahamsson wrote:
>>> My high level comment/question is: the proposed charter seems to
>>> stress that IPv6 is the driver behind this potential wg effort...
>>> however, I think that this deserves more discussion -- it's not clear
>>> to me why/how typical IPv6 home networks would be much different from
>>> their IPv4 counterparts.
>>
>> In my mind, I see the possibility of /56 PD enabling different subnets
>> for different kinds of devices with different security and functional
>> needs, and also chaining of L3 devices. This definitely warrants a group
>> to look at that.
>
>>> One would hope/expect that the former will be gone with IPv6. However,
>>> I don't think the latter will. As a result, even when you could
>>> "address" nodes that belong to the "home network", you probably won't
>>> be able to get your packets to them, unless those nodes initiated the
>>> communication instance.
>>
>> This is exactly why the whole "system" needs to work, including uPNP
>> like functionality for nodes to talk to the firewall(s).
>
> I think this deserves a problem statement that clearly describes what we
> expect to be able to do (but currently can't), etc. And, if this is
> meant to be v6-only, state why v4 is excluded -- unless we're happy to
> have people connect their IPv4-devices, and see that they cannot
> communicate anymore.
>
> Thanks,

-- 
Stephen [kiwin] Palm   Ph.D.                          E:  [email-masked]
Senior Technical Director                             T: +1-949-926-PALM
Broadcom Broadband Communications Group               F: +1-949-926-7256
Irvine, California                               W: http://www.kiwin.com
Secondary email accounts:  [email-masked]  [email-masked]
[email-masked]  [email-masked]  [email-masked]  [email-masked]

---

From: Keith Moore <[email-masked]>
Date: Thu, 30 Jun 2011 08:21:43 -0400

> networks in which stuff works for IPv6 differently from how it works for

hopefully!

> PD), but a single IPv4 subnet?

for that specific example, not clear.   my impression is that the architecture of home networks should work regardless of whether there's a single subnet or multiple subnets.

> heading in that direction.

nothing says that some results of the work can't also apply to IPv4.  but people are far too mired in outdated assumptions today, such as the idea that every network needs a NAT or a firewall that filters based on IP addresses and ports.

> leveraging IPv6), then that's fine... 

no, that's not fine.   that's painting ourselves (and the Internet) into a corner.

Keith

---

From: "Stephen [kiwin] PALM" <[email-masked]>
Date: Thu, 30 Jun 2011 07:55:40 -0700

Thanks Mark for stating that.
It would really be helpful if this type of text is included in the description/charter.
The lack of of this information in the recently distributed material caused
several immediate allergic reactions...

regards, kiwin

---

From: "Weil, Jason" <[email-masked]>
Date: Thu, 30 Jun 2011 11:06:18 -0400

Mark,

100% in agreement with this stance.

Just to echo what Fernando has already stated, you can't completely ignore
IPv4 in the home network especially when you are talking about a
multi-segmented network. For example RFC6204 calls for a separate /64 on
each LAN interface per the L-2 requirement. In IPv4 these interfaces
nearly always operate in bridged mode. Supporting bridged IPv4 and routed
IPv6 on the same physical interface could pose a challenge.

Overall I like the concept of not breaking core IPv4 functionality while
focussing all new functionality to IPv6.

Jason

On 6/30/11 5:57 AM, "Mark Townsley" <[email-masked]> wrote:

>around this topic can be summed up as stating that homenet deliverables
>will:
>
>In other words, anything we do for the IPv6 homenet cannot actively break
>what's already running on IPv4. Also, trying to define what the IPv4 home
>network should be has long reached a point of diminishing returns given
>the effort in doing so coupled with our ability to significantly affect
>what's already deployed. There's still hope we can help direct IPv6, as
>such that is homenet's primary focus.  However, when we can define
>something that is needed for IPv6 in a way that is also useful for IPv4
>without making significant concessions, we should go ahead and do so.
>
>- Mark
>
>
>
>> Chaining NAT boxes already work. I also feel that we shouldn't put in a
>>lot of work to develop IPv4 further, that focus should be put on IPv6.
>>
>>> I think this deserves a problem statement that clearly describes what
>>>we expect to be able to do (but currently can't), etc. And, if this is
>> IPv4 should be excluded because it's a dead end, and we all know it.
>>We're just disagreeing when it's going to die and how.
>>
>> --
>fun mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/fun

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: "Stephen [kiwin] PALM" <[email-masked]>
Date: Thu, 30 Jun 2011 08:09:50 -0700

> focussing all new functionality to IPv6.

It is more than just IPv4 functionality... it is all the deployed
applications and devices that utilize IPv4.... and for whatever
reason, cannot be "upgraded" to IPv6. 8-)

regards, kiwin

> On 6/30/11 5:57 AM, "Mark Townsley"<[email-masked]>  wrote:
>
>>

---

From: Mark Townsley <[email-masked]>
Date: Thu, 30 Jun 2011 17:13:59 +0200

> several immediate allergic reactions...

I'm happy to include it in the next rev.

- Mark

---

From: Keith Moore <[email-masked]>
Date: Thu, 30 Jun 2011 11:46:30 -0400

> - be IP-agnostic whenever possible

I'd like for this group to relax the "wherever possible" bit, so as to not preclude solutions where IPv6 can do a better job than IPv4.

IPv4 is a dinosaur gasping for its last breaths.

Keith

---

From: Fernando Gont <[email-masked]>
Date: Thu, 30 Jun 2011 12:59:20 -0300

> IPv4 is a dinosaur gasping for its last breaths.

Just curious: when you expect IPv4 to be gone? (including "gone" from
home and enterprise networks)

Thanks,

---

From: Keith Moore <[email-masked]>
Date: Thu, 30 Jun 2011 12:05:26 -0400

> home and enterprise networks)

I think it will be used for email and the web for at least ten years.
I think there will be a need to talk to legacy IPv4-only devices for about that long, perhaps a bit longer.
But IPv4 is already difficult to use for a great many applications, and it will only get worse with the imposition of LSN.  A home network that only supports IPv4, or which makes IPv6 as crippled as IPv4, is not a desirable goal.

Keith

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Thu, 30 Jun 2011 12:11:31 -0400

"Gone" isn't so important as "not worth expending any more energy on.". So I'm with Keith and would like to find some words like "when it doesn't take any more work."

- Ralph

---

From: "Stephen [kiwin] PALM" <[email-masked]>
Date: Thu, 30 Jun 2011 09:17:22 -0700

It is not for "us" to decide when a user's network is not worth expending
any more energy on. They have deployed their network...
and do not want to expend any more energy themselves.  If their SP deploys
IPv6 inelegantly, the user would have a lot of frustration/work.  Which
will generate many expensive tech support calls... and potentially lost customers.

It's not the protocols... it's the DEPLOYED APPLICATIONS and DEVICES that users have.

regards, kiwin

On 6/30/2011 9:11 AM, Ralph Droms (rdroms) wrote:
> On Jun 30, 2011, at 12:00 PM, "Fernando Gont"<[email-masked]>  wrote:
>

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Thu, 30 Jun 2011 12:21:37 -0400

> will generate many expensive tech support calls... and potentially lost customers.

Agreed that we need to avoid any disruptions of existing networks, devices and deployment scenarios.  I think we should avoid expending energy on *new* functions for IPv4.

- Ralph

---

From: Mark Townsley <[email-masked]>
Date: Thu, 30 Jun 2011 18:33:58 +0200

> I'd like for this group to relax the "wherever possible" bit, so as to not preclude solutions where IPv6 can do a better job than IPv4.

Yes, and I think that IPv6 should naturally do a better job than IPv4 in the cases where it can. 

My original mail had this restatement of the above, which I think gets closer to what you want:

>> However, when we can define something that is needed for IPv6 in a way that is also useful for IPv4 without making significant concessions, we should go ahead and do so.

- Mark

---

From: Keith Moore <[email-masked]>
Date: Thu, 30 Jun 2011 12:36:36 -0400

>>> However, when we can define something that is needed for IPv6 in a way that is also useful for IPv4 without making significant concessions, we should go ahead and do so.

when the group can define something that is useful in IPv6, it shouldn't matter whether it's also useful for IPv4.

please don't constrain home networks to work only within the confines of IPv4 brain damage.

Keith

---

From: james woodyatt <[email-masked]>
Date: Thu, 30 Jun 2011 11:21:13 -0700

> please don't constrain home networks to work only within the confines of IPv4 brain damage.

I suspect what Mr. Townsley and Mr. Arkko are aiming at here is that if FUN can come up with a scheme to make routed home subnetworks work with delegated IPv6 prefixes, then it is probably not too far-fetched that the same scheme could be trivially extended for assigning IPv4 subnets from the RFC 1918 private realm to support dual-stack routed home subnetworks.

I'm not expecting home networks to be able to run IPv6-only with the IPv4 Internet mapped to 64:ff9b::/96 through NAT64 for several more years yet.  There's a whole crapload of legacy IPv4-only devices in the average home theater system today that nobody wants to cut off from the Internet just yet.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 01 Jul 2011 01:10:57 +0200

I think this is a great WG proposal and I fully support it's creation.

However my ISP is telling me that it has sufficient pool of IPv4 
addresses for the min next 5-10 years so rolling v6 for residential 
users is completely not that much appealing to him.

IETF can build many specs recommending v6 deployments, protocol 
extensions and network architectures. Unfortunately before the day  when 
there is first attractive real content available online _only_ via v6 or 
when there is new killer app which works only over v6 I think the world 
will become more and more fragmented into islands of v4, v4v6 and v6 only.

The issue is not technical here and IETF will not I am afraid be able to 
fix it.

The issue is purely business driven and till all providers get clear 
message from their users that they must have v6 as they can not google 
anymore, pay their bills, use new fancy holographic movie downloader app 
(just as examples) the migration towards v6 may take not 10 but 50 to 
100 years.

Cheers,
R.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 01 Jul 2011 09:20:35 +1000

In message <[email-masked]>, james woodyatt wri
tes:
> I suspect what Mr. Townsley and Mr. Arkko are aiming at here is that if FUN c
> an come up with a scheme to make routed home subnetworks work with delegated 
> IPv6 prefixes, then it is probably not too far-fetched that the same scheme c
> ould be trivially extended for assigning IPv4 subnets from the RFC 1918 priva
> te realm to support dual-stack routed home subnetworks.
> 
> I'm not expecting home networks to be able to run IPv6-only with the IPv4 Int
> ernet mapped to 64:ff9b::/96 through NAT64 for several more years yet.  There
> 's a whole crapload of legacy IPv4-only devices in the average home theater s
> ystem today that nobody wants to cut off from the Internet just yet.

I'm expecting home nets to be dual stacked for 10+ years after IPv6
is common to the home (2-5) years.  If the home gateway has DS-Lite
support then that provides a better solution than NAT 444.  It also
continues to work when the home net goes IPv6 only with the home
gateway passing on the DS-Lite parameters from the ISP.

Consumer electronics lasts 10+ years.  I'm still using my DOCSIS
1.0 modem 8+ years.  My router hardware is 13+ years old, the
software is newer and is the 6in4 tunnel end point.  I've got TV's
of similar vintage.

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

---

From: james woodyatt <[email-masked]>
Date: Thu, 30 Jun 2011 16:51:29 -0700

On Jun 30, 2011, at 16:10 , Robert Raszuk wrote:
> 
> ...when there is new killer app which works only over v6...

There's another conditional that may be more relevant.

When there is a new "killer" application that doesn't work when one endpoint is IPv4-only and the other is attached to a 3GPP network with IPv6-only service and using NAT64 with the well-known 64:ff9b::/64 prefix, and optionally a bump-in-the-host to provide an IPv4 networking API to applications.  I happen to be aware of a whole family of interesting applications that are broken by such configurations, and I'm pretty sure they will remain broken into the foreseeable future.  Those configurations are already here in some parts of the Internet, and when these applications I'm thinking about are deployed on those networks (they are not currently, but... mene mene tekel upharsin), they will fail.

And whose fault will that be?  Not mine, brother.  Not mine.

Is your service provider breaking those awesome applications by not offering full dual-stack service?  If so, then you need to get a new service provider.  Either get one that offers full dual-stack over 3GPP so your applications can connect with IPv4-only endpoints, or get one that offers full dual-stack over first-mile wireline to your site, so your applications can connect to IPv4-impaired mobile endpoints.

The key thing here is that by Alice choosing to use one service provider over another, she can make Bob's application fail, and vice versa.  The mobile service providers that don't have enough IPv4 addresses to serve all their customers are in a bind and can't budge.  The wireline service providers who have 5-10 years of IPv4 addresses in reserve are the ones whistling past the graveyard.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 1 Jul 2011 07:23:47 +0200 (CEST)

On Thu, 30 Jun 2011, Martin Focazio wrote:

> You assume at Alice CAN select a service provider. In a large part of
> the USA your choices are nil. You have a single wireline provider or
> you don't have a connection.

I don't see why the IETF should spend time on IPv4 because of some 
political problem in certain countries which makes the market not work 
properly.

IPv4 is legacy, IPv6 is where the development effort should be, when IPv6 
offers more functionality then things will most likely sort themselves 
out.

Personally I believe video conferencing is the killer app. I have problems 
getting video calls to work when both are behind NAT, it works just fine 
with one person being behind NAT (and the other one not having firewall 
configured so it's stopping the traffic). With IPv6 we just need to sort 
out the firewall problem. My mom is very impressed by being able to 
videocall her grandchild and follow his development, and if I told her 
it'd cost 200 USD extra to make it work (better), either she or I would 
spend the money.