Subject: [homegate] HOMENET working group proposal

From: Jari Arkko <[email-masked]>
Date: Wed, 29 Jun 2011 10:47:18 +0200

I would like to announce a new effort around home networking and solicit 
some feedback.

HOMENET is a new working group proposal, a variation of the 
HOMEGATE/HOMENET theme that we discussed last year, but this time 
looking at it from a different angle. The old effort was mostly focused 
about what home gateways should do: forwarding, transport, and DNS 
proxying issues. The new effort is about home networks themselves, in 
particular what kind of network architecture and configuration is 
necessary to support IPv6-based home networks. We view IPv4-based home 
networks as "done" at this time (or perhaps as "cannot be changed anyway").

I have been discussing this effort in the background for the last couple 
of month with Mark Townsley and others, and more publicly since early 
June. The proposal has been brought to the IESG, IAB and some 
directorates for discussion, and we've been going back and forth whether 
this is ready to become a working group or needs to be run as a BOF in 
Quebec City. The current plan is that the working group proposal goes to 
IETF-wide review this week, and if the feedback from the community, IAB, 
and the IESG is positive, we will create the working group just in time 
for the IETF. Otherwise, the slot reserved in the agenda for the meeting 
will be used to run the proposal as a BOF.

In any case, I would like to solicit discussion on this topic, and 
perhaps some early drafts as well. Please comment on the charter at 
least. Go here to subscribe https://www.ietf.org/mailman/listinfo/fun 
and below you can find the most recent charter proposal. Please join the 
list and the discussion.

Note that the new proposal was called FUN at the time that we created 
the list. It has now been renamed back to HOMENET to be more 
descriptive. The list will be renamed soon as well (current subscribers 
will stay). Note also that I'm sending this to the old homegate list, to 
inform people who were interested in that. I'd like the discussion to 
happen on the [email-masked] list, however.

Jari

Home Networks (homenet)
-----------------------------------

Current Status: Proposed
Last Edit: Wednesday, June 29th, 2011

Chairs:
TBD

Internet Area Directors:
Ralph Droms <[email-masked]>
Jari Arkko <[email-masked]>

Internet Area Advisor:
Jari Arkko <[email-masked]>

Routing Area Technical Advisor:
TBD

Security Area Technical Advisor:
TBD

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: https://www.ietf.org/mailman/listinfo/fun
Archive: http://www.ietf.org/mail-archive/web/fun

Description of Working Group:

This working group focuses on the evolving networking technology
within and among relatively small “residential home” networks. For
example, an obvious trend in home networking is the proliferation of
networking technology in an increasingly broad range and number of
devices. This evolution in scale and diversity sets some requirements
on IETF protocols. Some of the relevant trends include:

o Multiple segments: While less complex L3-toplogies involving as few
subnets as possible are preferred in home networks for a variety of
reasons including simpler management and service discovery, the
introduction of more than one subnet into a home network is enough
to add complexity that needs to be addressed, and multiple
dedicated segments are necessary for some cases. For instance, a
common feature in modern home routers in the ability to support
both guest and private network segments. Also, link layer
networking technology is poised to become more heterogeneous, as
networks begin to employ both traditional Ethernet technology and
link layers designed for low-powered sensor networks. Finally,
similar needs for segmentation may occur in other cases, such as
separating building control or corporate extensions from the
Internet access network. Different segments may be associated with
subnets that have different routing and security policies.

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.

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.

Home networks need to provide the tools to handle these situations in
a manner accessible to all users of home networks. Manual
configuration is rarely, if at all, possible. The purpose of this
working group is to focus on this evolution, in particular as it
addresses the introduction of IPv6, by developing an architecture
addressing this full scope of requirements:

o prefix configuration for routers
o managing routing
o name resolution
o service discovery
o network security

The task of the group is to produce an architecture document that
outlines how to construct home networks involving multiple routers and
subnets. This document is expected to apply the IPv6 addressing
architecture, prefix delegation, global and ULA addresses, source
address selection rules and other existing components of the IPv6
architecture. The architecture document should drive what protocols
changes, if any, are necessary. Specific protocol work described below
is expected to be within the scope of the working group one the
architecture work is complete. However, the group is required to
review its charter and milestones with the IESG and IETF community
before submitting documents that make protocol changes. It is expected
that the group has to discuss some of the below solutions, however, in
order to complete the architecture work.

The group will apply existing protocols to handle the five
requirements above. For prefix configuration, existing protocols are
likely sufficient, and at worst may need some small enhancements, such
as new options. For automatic routing, it is expected that existing
routing protocols can be used as is, however, a new mechanism may be
needed in order to turn a selected protocol on by default. For name
resolution and service discovery, extensions to existing
multicast-based name resolution protocols are needed to enable them to
work across subnets.

For network security, the group shall document the concept of
"advanced security" as a further development of "simple security" from
RFC 6092. The main goal of this work is to enable a security policy
that adapts to IPv6 threats as they emerge, taking into account not
only traffic from the Internet at large, but within and leaving the
home network itself.

It is expected that the working group will define a set of protocol
specifications to accomplish the five requirements from
above. However, it is not in the scope of the working group to define
entirely new routing protocols or address allocation protocols. As
noted, additional options or other small extensions may be necessary
to use the existing protocols in these new configuration tasks. The
working group shall also not make any changes to IPv6 protocols or
addressing architecture. Prefix configuration, routing, and security
related work shall not cause any changes that are not backwards
compatible to existing IPv6 hosts. There may be host visible changes
in the work on naming and discovery protocols, however. In its design,
the working group shall also consider security aspects and the impact
on manageability. The main focus of the working group is home
networks, but the group's results may also find applications in other
small networks.

The working group will liaise with the relevant IETF working
groups. In particular, the group should work closely with the V6OPS
working group, review any use or extension of DHCP with the DHC
working group, and work with additional DNS requirements with the
DNSEXT and DNSOP working groups. If it turns out that additional
options are needed for a routing protocol, they will be developed in
the appropriate Routing Area working group, with the HOMENET working
group providing the architecture and requirements for such
enhancements. The working group will also liase with external
standards bodies where it is expected that there are normative
dependencies between the specifications of the two bodies.
It is expected that in the architecture definition stage liaising
with the Broadband Forum, DLNA, and UPnP Forum is necessary.

Milestones:

Jul 2011 Formation of the working group
Sep 2011 First WG draft on the architecture
Dec 2011 Submission of the architecture draft to the IESG as 
Informational RFC
Dec 2011 Charter re-evaluation based on the architecture work
Dec 2011 First WG draft on prefix configuration
Dec 2011 First WG draft on routing
Jan 2012 First WG draft on name resolution
Feb 2012 First WG draft on service discovery
Feb 2012 First WG draft on perimeter security
Feb 2012 Start of routing related work in the relevant routing area 
working group, if needed
Mar 2012 Submission of the prefix configuration draft to the IESG as 
Standards Track RFC
Apr 2012 Submission of the routing draft to the IESG as Informational RFC
Sep 2012 Submission of the name resolution draft to the IESG as 
Standards Track RFC
Nov 2012 Submission of the service discovery draft to the IESG as 
Standards Track RFC
Dec 2012 Submission of the perimeter security draft to the IESG as 
Informational RFC

---

From: Fernando Gont <[email-masked]>
Date: Wed, 29 Jun 2011 23:18:27 -0300

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

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:
[....]
> 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.

> 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!
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 29 Jun 2011 19:38:37 -0700

> not reachable from the public Internet.

The opportunity for restoring e2e is one of the great opportunities of ipv6
and it is my hope this new WG will drive that with facts and take on fud.

The utility of network based spi firewalls is debatable. Likely a never
ending debate.

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

---

From: Fernando Gont <[email-masked]>
Date: Wed, 29 Jun 2011 23:57:03 -0300

> The opportunity for restoring e2e is one of the great opportunities of

This assumes that e2e reachability is a desired property for all networks.

> and it is my hope this new WG will drive that with facts and take

Wasn't the simple/advanced security RFCs produced by v6ops aimed at
typical home devices?

Thanks,

---

From: Keith Moore <[email-masked]>
Date: Wed, 29 Jun 2011 23:20:51 -0400

On Jun 29, 2011, at 10:38 PM, Cameron Byrne wrote:
> The utility of network based spi firewalls is debatable. Likely a never ending debate.
> 

+1

---

From: Dan White <[email-masked]>
Date: Thu, 30 Jun 2011 00:11:23 -0500

>* an implicit "allow only return traffic" firewall-like functionality

I'll add a 3rd component, which is application protocol mangling.

What's given NAT a particularly bad name in recent years are the
consistently poor SIP ALG implementations in many home routers, along with
IPSEC ALGs, and other ALGs that attempt to fix the problem in the wrong
way.

End-to-end communication might be better approached as the desire to
default to a configuration in which ALGs are no longer necessary, and then
address firewalling separately, which could just as well default to a no
inbound connection policy.

>not reachable from the public Internet.

Home networks are bound to grow complex quite quickly. There's certainly
value in using a model that residential users are familiar with, but it
should be balanced by the inevitable need to address complexity that will
outgrow the ability of many users to manage.

A typically complex home network in the near future might be: alarm
systems, utility and environmental monitoring, lifeline SIP service (911),
Super Bowl broadcasts, etc., all connected via one home gateway device,
which may have several outsourced/managed devices installed behind it.

Having a simpler demarcation-like gateway device, which defers a lot of
that complexity to other components in the network (such as end-to-end
security), should go a long way in providing a sustainable model.

-- 
Dan White

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 30 Jun 2011 07:12:18 +0200 (CEST)

> typical IPv6 home networks would be much different from their IPv4 

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.

A more routed home instead of pure L2 one.

> get your packets to them, unless those nodes initiated the communication 

This is exactly why the whole "system" needs to work, including uPNP like 
functionality for nodes to talk to the firewall(s).

> not reachable from the public Internet.

I think this will also change, but not for all devices from all of the 
Internet. Still, I believe there is a place for a working group to look at 
this.

I have subscribed already.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Thu, 30 Jun 2011 03:51:36 -0300

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.

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)

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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 30 Jun 2011 09:25:29 +0200 (CEST)

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

> have people connect their IPv4-devices, and see that they cannot 

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.

---

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:

>> 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.
> 
> -- 
> homegate mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homegate

---

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: <[email-masked]>
Date: Thu, 30 Jun 2011 15:51:30 +0200

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mikael Abrahamsson
Sent: 30. juni 2011 07:12
To: Fernando Gont
Cc: [email-masked]; IETF Discussion
Subject: Re: [homegate] HOMENET working group proposal

> functionality for nodes to talk to the firewall(s).

UPnP like can indeed be UPnP.  The UPnP Forum has defined IPv6 firewall control as a part of UPnP now.
http://upnp.org/specs/gw/UPnP-gw-WANIPv6FirewallControl-v1-Service.pdf

Telenor, which I work for, is going to ask for this as a part of the IPv6 offering from our CPE vendors.

-Erik Taraldsen

---

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

-- 
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: "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
>
>
>
>>> 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: Fernando Gont <[email-masked]>
Date: Thu, 30 Jun 2011 12:59:20 -0300

On 06/30/2011 12:46 PM, Keith Moore wrote:
> 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.

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 11:46:30 -0400

Keith

---

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

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

---

From: Martin Focazio <[email-masked]>
Date: Thu, 30 Jun 2011 21:34:10 -0400

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

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.

---

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

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