[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Discussion of the Home/SOHO environment
On Jan 3, 2008, at 15:22, Fred Baker wrote:
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.
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.
On January 3, 2008 at 1:22:01 PM PST, Alain Durand
<alain_durand@cable.comcast.com> wrote:
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.
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 <jhw@apple.com>
member of technical staff, communications engineering