Subject: Discussion of the Home/SOHO environment

From: Fred Baker <[email-masked]>
Date: Thu, 3 Jan 2008 15:22:47 -0800

I am reporting back to the working group on the CPE REquirements  
design team, and specifically a question Alain raised this afternoon.  
I think it is something the IPv6 operational community, and by  
extension the IPv6 community, needs to think about. For context, I  
have included several emails from the thread including my own, which  
opened it, Alain's, which asked some very important questions, and my  
own reply to Alain's note. I have also included a couple of others  
which I thought were important.

I would like the v6ops community to discuss this and come to some  
conclusion that can guide the CPE Requirements development. It may be  
worthwhile documenting that conclusion and the assumptions it is  
based on in an RFC. We are dealing at least in part with a world view  
question, and we need a rational and agreed world view.

Begin forwarded message:

> From: Fred Baker <[email-masked]>
> Date: January 3, 2008 12:15:44 PM PST
> To: V6CPE Design Team <v6ops-residential-cpe-design- 
> [email-masked]>
> Cc: [email-masked], Kurt Erik Lindqvist  
> <[email-masked]>
> Subject: Wondering if we're on the same wavelength
>
> As we're going through this discussion, I'm wondering if we have it  
> structured right. It seems like we are not working on a single set  
> of requirements on which we basically agree, which is  
> characteristic of a design team. Rather, we have a very polarized  
> discussion between two very different sets of people. One set, the  
> folks who make CPEs, are being told in no uncertain terms by their  
> customers that they need to provide firewall functionality, and  
> some customers require NAT functionality for reasons unrelated to  
> firewalling. The other group, which AFAIK have no skin in the CPE  
> game, are (in some cases adamantly) opposed to the deployment of  
> firewalls.
>
> Would we have a more productive discussion if this were separated  
> into two separate teams and resultant documents, each describing  
> and arguing for its version of the universe? If so, who would like  
> to take the lead on the "we don't need no stinkin firewalls" model?

> From: Alain Durand <[email-masked]>
> Date: January 3, 2008 1:22:01 PM PST
> To: Fred Baker <[email-masked]>, V6CPE Design Team <v6ops- 
> [email-masked]>
> Cc: <[email-masked]>, Kurt Erik Lindqvist  
> <[email-masked]>
> Subject: Re: Wondering if we're on the same wavelength
>
> Fred,
>
> IMHO, what is missing is a broader understanding of what I call the  
> new "social contract" in IPv6 broadband land...
>
> In IPv4 broadband land, there is a pretty well accepted "social  
> contract":
>
>    - Customer get one IPv4 address that can change over time
>    - Customer use/rent/own a NAT box to create more address space,
>      isolate himself/herself from external IP address change, get
>      the so-called security benefits of NAT or whatever over local  
> reason
>    - the "security model" is mainly defined as: all devices within  
> the home
>      network belong to the customer, are mostly unmanaged and
>      a security perimeter is defined by the home router to  
> "protect" the
>      good inside from the "evil" outside.
>    - The ISP has very little if any view of the devices in the home  
> south
>      of the home gateway
>    - There is little DNS in place
>
> Note: all this is a direct consequence of the NAT model
>
> In the brave new world of IPv6, the plethora of address space  
> impose on us to revisit this model, mainly because NAT is not  
> required to connect more than one device. Note that I said not  
> required, which does not mean it will not be part of the picture in  
> one form or another, if only in the NAT v4/v6/v4 that I described  
> last IETF.
>
> So, IMHO, what is needed is for the industry at large (and not just  
> a few experts) to open up a discussion of what this social contract  
> now will look like in IPv6, in other words, what kind of networks  
> and network usage are we looking at, and not just now, but looking  
> ahead...
>
> Essentially, we must *collectively* answer a number of questions:
>
>    - How much space is assigned per customer
>      This is the trivial one that is being discussed right now
>    - Is there any routing within the home?
>    - Is this address space "stable" over time or is it expected
>      to be changeable by the ISP? There are huge ramification in the
>      local routing & provisioning complex depending how you answer  
> this
>      question
>    - What is(are) the management model(s) of the home?
>      Is the customer expected to manage alone his network? How can  
> the ISP
>      usefully help? What about in-home devices operated/owned/under  
> contract
>      with either the ISP or a 3rd party?
>    - What should be the new security model?
>    - How to manage the name space?
>
> I'm concerned we will not make much progress on the firewall issue  
> until we have a better understanding of the broader issue I  
> described above. And honestly, I think we are just at the very  
> beginning.
>
>    - Alain.

> From: Fred Baker <[email-masked]>
> Date: January 3, 2008 2:32:46 PM PST
> To: Alain Durand <[email-masked]>
> Cc: V6CPE Design Team <v6ops-residential-cpe-design- 
> [email-masked]>, <[email-masked]>, Kurt Erik  
> Lindqvist <[email-masked]>
> Subject: Re: Wondering if we're on the same wavelength
>
> You raise some important questions. I think there are some more you  
> need to ask.
>
> I have attached a network map of my home. It is somewhat out of  
> date; last summer, my folks-in-law moved in with us as as such as  
> now have TV service in the home, and as a result two set-top boxes.  
> They are right now on the TV coax apart from control, which is done  
> via a combination of a direct radio interface and the wifi network,  
> but in the future one might expect them to come onto the IP network  
> in full.
>
> On Jan 3, 2008, at 1:22 PM, Alain Durand wrote:
>> Fred,
>>
>> IMHO, what is missing is a broader understanding of what I call  
>> the new "social contract" in IPv6 broadband land...
>>
>> In IPv4 broadband land, there is a pretty well accepted "social  
>> contract":
>>
>>    - Customer get one IPv4 address that can change over time
>>    - Customer use/rent/own a NAT box to create more address space,
>>      isolate himself/herself from external IP address change, get
>>      the so-called security benefits of NAT or whatever over local  
>> reason
>>    - the "security model" is mainly defined as: all devices within  
>> the home
>>      network belong to the customer, are mostly unmanaged and
>>      a security perimeter is defined by the home router to  
>> "protect" the
>>      good inside from the "evil" outside.
>>    - The ISP has very little if any view of the devices in the  
>> home south
>>      of the home gateway
>>    - There is little DNS in place
>>
>> Note: all this is a direct consequence of the NAT model
>
> I'll add that they are also consequences of ownership. The ISP, Cox  
> Business Services in my case, supplies the Cable Modem and the set- 
> top box, but apart from that the equipment in my home belongs to  
> me. As a customer, I would be very surprised if my ISP tried to  
> assert any control over anything it didn't own apart from a  
> specific contractual agreement permitting it to do so. It would be  
> enough for me to terminate my contract with the ISP. If my ISP  
> announced to me that it thought there was a new social contract  
> that I as a consumer was supposed to accept but was not a party to,  
> that would likewise be the end of my legal contract. The services  
> my ISP offers in my home are there because I choose them and choose  
> to pay for them, not because the ISP wants them to be there.
>
>> In the brave new world of IPv6, the plethora of address space  
>> impose on us to revisit this model, mainly because NAT is not  
>> required to connect more than one device. Note that I said not  
>> required, which does not mean it will not be part of the picture  
>> in one form or another, if only in the NAT v4/v6/v4 that I  
>> described last IETF.
>
> Certainly, as a customer I expect to have my router obtain an  
> address (ND or DHCP) and other configuration information, including  
> a delegated prefix.
>
>> So, IMHO, what is needed is for the industry at large (and not  
>> just a few experts) to open up a discussion of what this social  
>> contract now will look like in IPv6, in other words, what kind of  
>> networks and network usage are we looking at, and not just now,  
>> but looking ahead...
>>
>> Essentially, we must *collectively* answer a number of questions:
>>
>>    - How much space is assigned per customer
>>      This is the trivial one that is being discussed right now
>
> yes.
>
>>    - Is there any routing within the home?
>
> I suspect that there are multiple classes of home here. In my case,  
> my company's information security policy requires me to have  
> routing in the home - by whatever means, my office equipment is not  
> accessible from the rest of my home.
>
>>    - Is this address space "stable" over time or is it expected
>>      to be changeable by the ISP? There are huge ramification in the
>>      local routing & provisioning complex depending how you answer  
>> this
>>      question
>
> That relates to some of the questions in RRG. If my ISP is  
> designing the network in my home, I guarantee that the home will  
> not be multihomed. Since that is not reality (my home isn't  
> multihomed, but Kurtis' and Jari's are), ergo, the ISP is not  
> designing or managing the network in my home. This in part is the  
> issue being addressed in draft-baker-6man-multiprefix-default- 
> route; if I in fact have multiple prefixes in the home, I want to  
> send my datagrams using an address to the ISP that gave me the  
> address. This is a lot easier with Metro Addressing (the ISPs  
> manage a prefix for the routing domain, which may be similar to a  
> geographical region) or with a GSE-like model such as Christian  
> Vogt suggests.
>
> In any event, if the ISP is provisioning me with a prefix, and I am  
> routing in the home, I expect to have a rational system for using  
> that prefix.
>
>>    - What is(are) the management model(s) of the home?
>>      Is the customer expected to manage alone his network? How can  
>> the ISP
>>      usefully help? What about in-home devices operated/owned/ 
>> under contract
>>      with either the ISP or a 3rd party?
>
> I expect the set-top box and other devices supporting services that  
> I contract for to come with instructions for what I am supposed to  
> do with them in my home. The ISP is a guest in my home, or perhaps  
> a servant like the maid or the butler, and will be replaced the  
> instant it forgets that.
>
>>    - What should be the new security model?
>
> yes.
>
>>    - How to manage the name space?
>
> Why would management of the name space for my home be different for  
> IPv6 than it would be for IPv4? At the end of the day, if I am  
> offering services from my home and using DNS to do them, I would  
> like the fact of getting an A or a AAAA record to be something I  
> only discover after the fact, not something inherent in the name.

> From: Mark Smith <[email-masked]>
> Date: January 3, 2008 1:50:43 PM PST
> To: Fred Baker <[email-masked]>
> Cc: V6CPE Design Team <v6ops-residential-cpe-design- 
> [email-masked]>, [email-masked], Kurt Erik  
> Lindqvist <[email-masked]>
> Subject: Re: Wondering if we're on the same wavelength
>
> I think there are three universes :
>
> 1) all end devices don't do firewalling, so the CPE has to do that  
> for them
>
> 2) some end devices don't do firewalling, so the CPE has to do that  
> for them. For the devices do do firewalling, how can we stop the  
> CPE firewall getting in their way
>
> 3) all end devices do firewalling, so the CPE shouldn't, because  
> it'll only get in the way
>
> Actually, thats more of a continuum than 3 separate universes.
>
> My argument is that it's trending towards 3. Because IPv6 is new(ish),
> it's possible that with IPv6 we might reach 3 much more quicly than
> we'll ever reach it in IPv4.
>
> That being said, it has occured to me that we might have overlooked
> that there's already lots of IPv6 CPE in Asia, and lots of IPv6  
> enabled
> devices available (STBs, CCTV cameras etc.) Maybe we should find out
> how they've approached the problem before we spend time resolving it.
>
> Regards,
> Mark.

> From: Iljitsch van Beijnum <[email-masked]>
> Date: January 3, 2008 2:15:55 PM PST
> To: Alain Durand <[email-masked]>
> Cc: Fred Baker <[email-masked]>, V6CPE Design Team <v6ops- 
> [email-masked]>, <v6ops- 
> [email-masked]>, Kurt Erik Lindqvist <[email-masked]>
> Subject: Re: Wondering if we're on the same wavelength
>
> On 3 jan 2008, at 22:22, Alain Durand wrote:
>
>> Essentially, we must *collectively* answer a number of questions:
>
> [...]
>
>> I'm concerned we will not make much progress on the firewall issue  
>> until we
>> have a better understanding of the broader issue I described  
>> above. And
>> honestly, I think we are just at the very beginning.
>
> I largely agree.
>
> Would it be useful to see if we can define a number of deployment  
> scenarios and then present those to the community at large it/we  
> can reach consensus about which ones we should go forward with?
>
> There are currently many discussions going on about bridging/ 
> routing CPEs, address provisioning, internal subnet allocation etc  
> (and some of those discussions weren't even started by me!). Until  
> we have some industry-wide agreement on this stuff rolling out IPv6  
> for consumers will be very complex.
>
> As to Fred's question: I think it's useful to hash things out here,  
> ignoring the occassional rant it seems we can find a decent amount  
> of common ground. If we go off in separate groups that only means  
> we'll have to have these fights in public... On the other hand, if  
> the CPE builders feel they can do better work without the firewall  
> skeptics I can live with that.

---

From: David Miles <[email-masked]>
Date: Fri, 4 Jan 2008 13:25:47 +1100

We must be mindful of the finite timeframe CPE vendors have to adopt  
any recommendations that come out of the IETF. Remarkably the IPv6  
message is sinking into large carriers and timings are being  
discussed, with ~2010 being the "date" that I have heard used most  
widely used for commercial service. With larger carriers, many persons  
are involved to bring a new product to commercial service and this can  
take up to 6 months, usually with trials prior. My own timelines  
require IPv6-capable CPE in mid-2009. If we do debate these items I  
would suggest strict deadlines be imposed. Can others give their views/ 
opinions on timing?

Managing a transition to a new protocol is going to be difficult, but  
trying to change the agreed norm 18-months prior to large-scale trials  
is something that the teams must view with a good appreciation of the  
risks. Commentary on IPv6 has already labelled it [IPv6] complex and  
over-engineered, and I do not believe that a protocol-level working  
group should be trying to address such a large issue as "are firewalls  
good things"? This is not an IPv6-specific debate, yet I feel it's  
being captured under the mantra of "do it once, do it right". For the  
CPE team themselves, do we need all these questions answered to get  
the firewall design done?

For the other topics, I agree we should throw ideas into the pot and  
see which float and which sink - let's be sure to work with the other  
standards bodies such as DSL Forum and CableLabs on some of this? Is  
there a liaison between IETF and DSLHome/CableHome?

There are existing solutions for some of the questions that have been  
posed - after all, IPv6 is just a network-layer protocol? The  
questions posed about home networks are defiantly interesting and  
useful, groups such as DSLHome and CableHome have created (and  
deployed) specifications to manage parts of the home network.

Address space stability is imperative from the perspectives of a  
number of carriers I have spoken with - a by-product of NAT was to  
allow WAN (carrier assigned) and LAN (customer assigned) to be  
addressed independently. In IPv6 your LAN addresses are carrier- 
assigned and this will be one of the most significant shifts from  
today's IPv4+NAT world. The stability we have advocated is one where  
you can keep your IPv6 prefix for as long as you remain at your  
residence even if the ISP network rearranges around you (node splits,  
BRAS de-loading, etc). This requires a certain amount of pre-planning  
to avoid RIB blow-outs but can be done. While IPv6 supports it, it  
would be resource intensive for edge routers to support transitioning  
from one prefix to another with multiple prefixes simultaneously active.

Name services for IPv6 is somewhere we have already begun looking at.  
In fact, one reason we are considering the target use of DHCPv6 in the  
home is to allow a central location of hosts for DNS updating (either  
through DHCPv6 FQDN option or web-portal). In this model the DHCPv6  
server would update the DNS server.

My view is that IPv6 will re-open doors for applications developers  
that have been long since shut, this will happen gradually and not  
overnight - after all if you develop an application that leverages  
IPv6, you need to wonder how many customers you can actually get on  
the new protocol.

Regards,

-d

On 04/01/2008, at 10:22 AM, Fred Baker wrote:

> design team, and specifically a question Alain raised this  
> afternoon. I think it is something the IPv6 operational community,  
> and by extension the IPv6 community, needs to think about. For  
> context, I have included several emails from the thread including my  
> own, which opened it, Alain's, which asked some very important  
> questions, and my own reply to Alain's note. I have also included a  
> couple of others which I thought were important.
>
> conclusion that can guide the CPE Requirements development. It may  
> be worthwhile documenting that conclusion and the assumptions it is  
> based on in an RFC. We are dealing at least in part with a world  
> view question, and we need a rational and agreed world view.
>
> Begin forwarded message:
>
>> To: V6CPE Design Team <[email-masked] 
>> >
>> Cc: [email-masked], Kurt Erik Lindqvist <[email-masked] 
>> >
>> To: Fred Baker <[email-masked]>, V6CPE Design Team <[email-masked] 
>> >
>> Cc: <[email-masked]>, Kurt Erik Lindqvist <[email-masked] 
>> >
>>     a security perimeter is defined by the home router to "protect"  
>> the
>> Cc: V6CPE Design Team <[email-masked] 
>> >, <[email-masked]>, Kurt Erik Lindqvist <[email-masked] 
>> >
>> Cc: V6CPE Design Team <[email-masked] 
>> >, [email-masked], Kurt Erik Lindqvist  
>> <[email-masked]>
>> Cc: Fred Baker <[email-masked]>, V6CPE Design Team <[email-masked] 
>> >, <[email-masked]>, Kurt Erik Lindqvist <[email-masked] 
>> >
> <Fred_home_network.pdf>

---

From: james woodyatt <[email-masked]>
Date: Thu, 3 Jan 2008 18:45:09 -0800

> view question, and we need a rational and agreed world view.

Mr. Durand suggests that IPv6 presents service providers with an  
opportunity to offer a new, revised social contract to retail ISP  
customers, i.e. a very different one from the traditional social  
contract that IPv4 service providers have been offering, and with  
which retail customers have grown accustomed.

> one form or another, if only in the NAT v4/v6/v4 that I described  

I couldn't agree more, but as one of those players with "skin" in the  
retail CPE development game, I'd like to point out that our customers  
are highly resistant to learning the difference between IPv4 and  
IPv6.  They don't want to know, and they really don't see why they  
should have to care.  Frankly, neither do I— on both counts.

The new IPv6 social contract needs to be functionally equivalent to  
the familiar old IPv4 one, or IPv6 service will have to be sold  
separately and marketed as an *alternative* to IPv4, not a complement  
to it.  I'm pretty sure no one wants that (but I'll allow that I  
could be insufficiently cynical).

If we're going to revisit the IPv4 social contract for the brave new  
world of IPv6 broadband retail service, here's what I think it will  
have to look like to keep from scaring our customers:

...beginning with the proposition that what they already know isn't  
going anywhere...

+ Customer gets one IPv4 address, possibly from RFC 1918 space, that  
may change over time, sometimes several times per day.  (I know of  
one service that changes my address six or seven times while I'm in  
transit between Cupertino and San Francisco.)
+ Customer uses/rents/owns an IPv4 NAT-gateway with all the  
traditional behaviors and idiosyncracies.
+ The ISP has very little, if any, view of the devices in the private  
IPv4 interior subnet south of the NAT-gateway.
+ The ISP offers very little, if any, DNS content service on behalf  
of the customer for their one IPv4 address.

...in addition...

+ Customer gets one global, provider-aggregated, unicast IPv6  
prefix.  (We can argue about the size.  I have reasons for wanting / 
48 over /56.  I'm willing to haggle.)
+ Customer prefix may change over time, preferably with new prefixes  
added while the old one is deprecated and still usable for some  
additional time (measured in hours and maybe days).
+ Interior routing in the customer premises, if any, will be  
controlled by the customer, not the service provider.  Zero  
configuration ad-hoc routing is how this will happen, if it does at all.
+ The IPv4 NAT-gateway owned/used/rented by the customer also serves  
as the IPv6 default gateway for their one IPv6 prefix.
+ On the customer interior network, the IPv6 gateway advertises its  
default route with RA.  It may optionally offer nodes additional  
configuration parameters, under the administrative control of the  
customer, using DHCP6.  Nodes without DHCP6 clients still get service  
by stateless autoconfiguration.
+ The ISP has very little, if any, view of the devices in the  
interior IPv6 network south of the gateway.  (Our customers are  
downright truculent about this point.  It's not a negotiable  
position.  If IPv6 means changing this on them, then IPv6 is DOA.)

...finally, and this is IMPORTANT...

+ Customers with public IPv4 addresses get satisfactory 6to4 relay  
service.
+ Customers with RFC 1918 addresses get satisfactory Teredo service.

(Why are these transition mechanisms important?  Because there's  
already a lot of installed gear that only supports IPv6 through one  
or both of these tunneling methods.  When IPv6 addresses start flying  
around in application protocols, and devices using this existing gear  
start trying to communicate with nodes that have native IPv6 service,  
everything needs to work whether it's tunneled or not.  Routing all  
my clients' IPv6 traffic (native from their perspective) through  
Ouagadougou because you don't think 6to4 service is important enough  
to treat with the same respect you treat your own native IPv6 transit  
is a great way to make me turn off IPv6 on all my servers and force  
all your IPv6-only customers to use the NAT-PT box you're still  
refusing to deploy.)

All the other questions Mr. Durand asks need to have the same answers  
for IPv6 as they currently do for IPv4.

Q: What is the management model of the home?
A: Zero configuration everywhere.  Fire and forget provisioning.   
Plug in the router, authorize it once, and never mess with it again.   
The ISP can only usefully help by assisting with troubleshooting when  
connectivity fails.

Q: What is the "security model" of the home?
A: All devices within the interior network are in the customer's  
possession, mostly unmanaged, and the perimeter is defined by the  
gateway to "protect" the good inside from the "evil" outside.   
(Customer expectations about how this works for IPv4/NAT need to be  
respected when considering how to make this work for IPv6, i.e.  
packets from exterior nodes are not forwarded unless expressly  
invited by an interior node, or by the customer opting to configure  
the router manually to allow them to pass.)

Q: What about devices on the interior network operated/owned/under  
contract with the ISP or a 3rd party.
A: Those devices initiate outbound flows through the gateway to "call  
home" for monitoring and control.

Q: How to manage the namespace?
A: The ISP offers very little, if any, DNS content service on behalf  
of customers, i.e. autogenerated ip6.arpa PTR records would be a  
luxury add-on.

I can think of other questions worth posing.

Q: What about mobile IPv6?
A: The home agent is either in the IPv6 gateway itself, or on the  
exterior network somewhere.  It isn't in the interior network unless  
the customer is weird and deliberately puts it there for some damned  
reason, and she knows why she's doing it.

Q: What about multicast routing?
A: Customers can subscribe to global scope multicast, both SSM and  
ASM w/ embedded RP address.  They may need to pay extra to originate  
global scope SSM (especially if ISP usually expects to change  
customer prefixes with any frequency).  Originating ASM with embedded  
RP addresses may also be supported in a similar manner if the RP is  
integrated with the IPv6 gateway.  The IPv6 gateway is an  
organizational scope multicast boundary by default.

Q: What about devices on the interior that shouldn't have global  
addresses?
A: Don't let them accept router advertisements, and let them use only  
link-local addresses.  (If you want them reachable through IPsec  
tunnel-mode terminated at the IPv6 gateway, then let the gateway  
offer a ULA prefix in addition to the globally reachable one.  Let  
the IPsec tunnel be the way the ULA prefix is reached from the  
exterior network.  Such devices ought to be configurable to refuse  
prefix advertisements outside the ULA range.)

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: james woodyatt <[email-masked]>
Date: Thu, 3 Jan 2008 19:00:04 -0800

On Jan 3, 2008, at 18:25, David Miles wrote:
>
> While IPv6 supports it, it would be resource intensive for edge  
> routers to support transitioning from one prefix to another with  
> multiple prefixes simultaneously active.

Actually, no it isn't.  The IPv6-enabled Internet gateway my employer  
sells today does this.  Every time the public IPv4 address changes,  
the IPv6 6to4 interior prefix moves.  It was a piece of cake to make  
this work.  I didn't even break a sweat.

> Name services for IPv6 is somewhere we have already begun looking  
> at. In fact, one reason we are considering the target use of DHCPv6  
> in the home is to allow a central location of hosts for DNS  
> updating (either through DHCPv6 FQDN option or web-portal). In this  
> model the DHCPv6 server would update the DNS server.

Why bother?  You're not letting them run servers on their home  
networks anyway.  Why do their nodes need to have names, much less  
names in your DNS zones?  Answer: they don't, so don't kill yourself  
trying to solve a problem you don't have.

> IPv6, you need to wonder how many customers you can actually get on  

My view is that IPv6 doesn't actually open any doors that are  
currently shut.  All it does, *ALL* it does, is stave off the  
impending scarcity of public IP addresses by injecting enough supply  
into the market that they remain too cheap to bother benchmarking for  
the foreseeable future.  None of the other features of the new  
protocol are visible or ever will be visible to application  
developers in any meaningful sense.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 04 Jan 2008 17:47:11 +1300

On 2008-01-04 16:00, james woodyatt wrote:
> sells today does this.  Every time the public IPv4 address changes, the 
> IPv6 6to4 interior prefix moves.  

That's not quite the same as running with several simultaneous
prefixes, though. I agree that this ought to work painlessly too,
since it's a design feature of IPv6, but the CPE will have to
actually support it, and so will all the consumer devices.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 04 Jan 2008 17:51:38 +1300

On 2008-01-04 15:45, james woodyatt wrote:
...
> + Customers with public IPv4 addresses get satisfactory 6to4 relay service.

That's presumably a requirement on the ISP. The requirement
on the CPE is to act as a 6to4 router, i.e. implement RFC 3056.

     Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 4 Jan 2008 08:36:24 +0100 (CET)

On Thu, 3 Jan 2008, james woodyatt wrote:

> + Customer gets one IPv4 address, possibly from RFC 1918 space, that may 
> change over time, sometimes several times per day.  (I know of one service 
> that changes my address six or seven times while I'm in transit between 
> Cupertino and San Francisco.)

I don't think this is something customers WANT. At a previous employer our 
ADSL offering consisted of a static IP address provisioned at deployment 
time with no dynamic what so ever.

This was appreciated by operational staff at the ISP (no servers involved 
in the function of getting IP packets flowing meant less outages and 
simpler service to fault isolate in case of trouble. Also no tools needed 
to find who had what IP at what time in case of abuse, IP/user correlation 
always the same) and by customers (we had customers that chose our service 
just because they got a static IP address). After a while we ended up 
giving out that static IP address via DHCP (same answer every time) as 
well just because we needed to provision VoIP service box.

So I would say that the changing of IP addresses is something ISPs have 
forced on customers and not something they choose themselves. It is my 
firm opinion that most customers want the same IP over time. Power users 
want it today, the majority will want it in the future (right now they 
don't care). As streaming devices etc are becoming more prevalent, I see 
users wanting to access their home devices from their mobile terminal for 
instance and this requires globally routed IPs.

ISPs not giving end customers the flexibility that is possible is going to 
have problems in markets where customers have a choice. I keep my ssh 
sessions running for days, so an ISP that changes my IP constantly is just 
simply unacceptable.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: David Miles <[email-masked]>
Date: Fri, 4 Jan 2008 19:13:30 +1100

Brian and James,

I should have been more specific - my comments were for BNG/BRAS (as  
that is the space I play in) that describe a situation where the ISP  
needs to change the original prefix (call it prefix-A) to a new prefix  
(call it prefix-B).

Yes, IPv6 the protocol and DHCPv6 Prefix Delegation support such a  
concept (delegating a new prefix(-B) and allowing the lifetime to  
expire on prefix-A while allowing both to be routed). I was pointing  
out that this will (in my view) consume needless resources on a BNG/ 
BRAS ultimately limiting the scalability and increasing the cost for  
carriers to adopt IPv6. This will also be increase implementation  
complexity as now the subscriber has (up to) three DHCP states -  
DHCPv4, DHCPv6 Prefix-A and DHCPv6 Prefix-B - for the BNG (and the  
ISP) to keep track of.

We would rather avoid the need for such a requirement and keep to a  
single "static" prefix per subscriber. As Mikael said (and I agree  
with), subscriber do not want the global-unicast addresses on their  
LAN to change.

-d

On 04/01/2008, at 3:47 PM, Brian E Carpenter wrote:

>> Actually, no it isn't.  The IPv6-enabled Internet gateway my  
>> employer sells today does this.  Every time the public IPv4 address  
>> changes, the IPv6 6to4 interior prefix moves.
>

---

From: Remi Denis-Courmont <[email-masked]>
Date: Fri, 4 Jan 2008 15:43:42 +0100

On Fri, 04 Jan 2008 17:51:38 +1300, Brian E Carpenter

> on the CPE is to act as a 6to4 router, i.e. implement RFC 3056.

I am very much mixed on this.

Yes, implementing a zero-configuration 6to4 relay on the CPE, if:

- it has a public IPv4 address, and

- it has native IPv6

will improve connectivity a lot... if 6to4 actually works.

I have seen several different networks where you get public IPv4

addresses, yet 6to4 does not work properly:

- because proto-41 is black-holed by the ISP, and/or

- because of stateful firewalling.

The second bullet is a minor issue for a 6to4 relay, but it is

a critical issue for a 6to4 gateway. Another argument against

zero-configuration 6to4 gateways is that you cannot check

whether the anycast relay actually works at the other end.

Unless we invent some kind of sanity checks for automatic

RFC3056, I'd rather CPEs avoid doing this by default...

With Teredo, these relaying issues mostly don't exist because

it has some kind of connectivity checks, but it comes at a

significant higher complexity from the CPE.

-- 

Rémi

---

From: james woodyatt <[email-masked]>
Date: Fri, 4 Jan 2008 10:27:14 -0800

On Jan 3, 2008, at 20:47, Brian E Carpenter wrote:
>> employer sells today does this.  Every time the public IPv4  
>> address changes, the IPv6 6to4 interior prefix moves.
>

It's basically the same thing if you count the private IPv4 subnet  
and the IPv6 link-local prefix along with the globally reachable IPv6  
prefix.

Looked at this way, Apple's home gateway products have supported  
multiple Internet subnet/prefixes for several generations now.  We  
went with IPv6 link-local a long time ago, mainly because multihoming  
in IPv4 is a huge pain in the neck, and just about every machine we  
sell can (and frequently does) operate multihomed on IEEE 802.3 and  
IEEE 802.11 at the same time.  Having more than one IPv6 prefix on  
the same interface is just a wrinkle on the more general problem of  
having more than one Internet protocol address and/or multiple  
network interfaces.

 From the perspective of the social contract to which service  
providers and consumers subscribe, there is nothing really new here.   
Consumers are already used to having their operating systems (and  
consumer devices) manage the multihoming problem for them, and they  
really shouldn't be any more inconvenienced by having their IPv6  
prefix change out from under them than they are by having their IPv4  
address changed out from under them.  ISP's are doing the latter all  
the time, and I have no reason to believe they won't find reasons to  
do the former as well— if, for no other reason than to protect their  
carefully traffic-engineered networks from growing congested because  
their customers attempt to run unauthorized servers.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 06 Jan 2008 09:42:54 +1300

Rémi,

> RFC3056, I'd rather CPEs avoid doing this by default...
In fact, 6to4 was not invented for the SOHO scenario. We were
mainly thinking of managed sites such as campuses where
the same people would be configuring the 6to4 router and
the firewall, not to mention doing explicit IPv6 routing.

> significant higher complexity from the CPE.

Yes, and Teredo was invented exactly to deal with the issues
raised by 6to4 in a SOHO environment.

    Brian

---

From: shogunx <[email-masked]>
Date: Sat, 5 Jan 2008 16:35:03 -0500 (EST)

> raised by 6to4 in a SOHO environment.

Surely there is a better way than that kludge though.  Given that NAT
also is a kludge, we really should earnestly consider how to NOT build on
top of it... otherwise, we run the risk of a very nasty stack down the
road.  At worst we should be able to encourage firmware updates for those
NAT boxes... radvd works very well.  At best the CPE should be
providing v6, perhaps making a bridge interface to the v6 router in the
NOC upstream.

Scott

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 06 Jan 2008 10:42:58 +1300

> providing v6, perhaps making a bridge interface to the v6 router in the

I agree, but that requires the CPE vendors and the ISPs to accept
a common scenario. Maybe we should propose one...

    Brian

---

From: shogunx <[email-masked]>
Date: Sat, 5 Jan 2008 16:55:04 -0500 (EST)

> a common scenario. Maybe we should propose one...

Now that sounds like a great idea.  Show them the map and lead them to
where X marks the spot.  CPE vendors... not so tough, I think.
Cisco is making the mass majority of those deployed anyway, correct?  If
they implement, everyone else will likely do the same to keep up with the
Jones'.  ISPs... They will likely want a mechanism to monetize v6 address
space like they did at $10 each with v4.  I'll wager they will play ball
if that possibility is evident to them.

Scott

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Sun, 6 Jan 2008 10:03:55 +0200

Le Saturday 05 January 2008 23:35:03 shogunx, vous avez écrit :
> Surely there is a better way than that kludge though.

Errrr, nobody (sane) would ever propose that CPE have to be Teredo gateways to 
access the IPv6 Internet. For a very simple reason. Contrary to 6to4, there 
is no such thing as a Teredo gateway. Teredo gives you a single address, not 
a /48 prefix as 6to4 does.

> Given that NAT also is a kludge, we really should earnestly consider how to
> NOT build on top of it... otherwise, we run the risk of a very nasty stack
> down the road.  At worst we should be able to encourage firmware updates for
> those NAT boxes... radvd works very well.  At best the CPE should be

The point here is, IPv6 will be *more* reliable if CPEs *with* native IPv6 
also have a Teredo relay. The only use of the Teredo relay is to reach third 
parties using Teredo; it does not affect the "normal" IPv6 connectivity at 
all.

Yet, I do expect most CPEs not to provide a Teredo relay, because the of the 
extra complexity and cost for the CPE vendor. However, the CPE requirements 
have to be consistent: if the CPE wants to block IPv4 port 3544, it really 
really should provide a Teredo relay. Otherwise, it is effectively decreasing 
the reliability of the IPv6 world.

-- 
Rémi Denis-Courmont
http://www.remlab.net/