Re: unmanaged scope comments (fwd)

[Ronald van der Pol <Ronald.vanderPol@rvdp.org>]

On Mon, Nov 18, 2002 at 00:07:06 +0200, Pekka Savola wrote:

> I was a bit frustrated to note that my earlier comments on unmaneval-00 
> weren't replied to, or taken into account in -01.

Sorry about that. Your email is in my inbox, and parts were discussed
within the design team. But we should have sent a reply.

> One of the biggest issues is that there seems to an assumption that
> unmanaged networks always employ (from ISP and/or internally) NAT.  That
> restricts the applicability unnecessarily.

You told me about bridged dsl in Finland which offers several global
v4 addresses. I think the specific v4 situation does not matter that
much. The main requirement is that v4 connectivity should not worsen
when you transition to v6.

> 1) Especially for case A and C.  I think there needs to be a clearer
> characterization of (IPv4) connectivity and addresses, like (this has all
> cases I think -- it could be simplified):
>
>  1. global addresses
>   a) dynamic
>       - enough addresses for every node
>       - only one

Yes, we realized we do not discuss dynamic v4 addresses. We probably
should.

> 2)
>
> 4     Application requirements of an IPv6 unmanaged network
>
> The application requirements are expressed in mostly three
> dimensions: connectivity, naming, and security. Connectivity issues
> include the provision of IPv6 addresses and their quality: do host
> need a global scope address, should this address be stable, or more
> precisely what should be the expected lifetime of the address.
>
> ==> connectivity includes one very important component IMO: the quality of
> network connections.  This is often ignored.  It's a high risk for a vendor
> to enable IPv6 by default, for example, if that'd result in lower quality
> connections to e.g. dual-stack web servers (a very real fact in 6bone), this
> should be taken into consideration at least in the short term.

I think this is YACEP (Yet Another Chicken and Egg Problem). Routing is
bad because people don't use v6 on a daily basis. And people don't use
v6 (upgrade services to dual stack) because routing is bad. But this is
not specific to unmanaged networks. It could go in a general BCP.

> 5.1	Case A, host deployment of IPv6 applications
> 
> In this case the gateway doesn't provide IPv6; the ISP may or may
> not provide IPv6, but this is not relevant, since the non-upgraded
> gateway would prevent the hosts from using the ISP service. Some
> hosts will try to get IPv6 connectivity, in order to run
> applications that require IPv6, or work better with IPv6.
> 
> ==> This is not true I think: for example, even if gateway runs v4 private
> addresses, ISP could provide e.g. internal tunnel service or something like
> ISATAP to their v6-enabled network.

I think this is meant:
"the ISP may or may not provide *native* IPv6"

> ==> Do you refer to *layer 3* gateway?  (Otherwise, this gets simpler with
> e.g. bridged ATM encapsulation in xDSL).

Yes, should we discuss bridged networks? Are they widely deployed or are
they corner cases?

> 6)
> 
> 5.1.1	Application support in Case A
> Server applications are also not a primary focus of Case A. Server
> applications require DNS support, which is difficult to engineer for
> clients located behind a NAT. Besides, server applications, at this
> stage, cater mostly to IPv4 clients; putting up an IPv6 only server
> is not very attractive.
> 
> ==> I'm not quite sure how DNS support is difficult to engineer; this
> probably has an unstated assumption that the address behind NAT would change
> too often to be really updateable or writable in DNS.  This does not need to
> be the case.

Maybe its not so much DNS which is the problem, but the server port mapping.
How would you do this unmanaged?

> ==> In case A, clients don't necessarily need to be behind a NAT.

The question is what percentage of SOHOs use NAT. If it is the vast
majority, I don't think we should complicate the draft even further.

> The security of server applications depends mostly on the
> correctness of the server, and also on the absence of collateral
> effects: many incidents occur when the opening of a server on the
> Internet inadvertently enables remote access to some other services
> on the same host.
> 
> ==> s/host/node/
> ==> not necessarily only the same node, even on the same local network
> ==> does 'correctness of the server' refer to the server application?

I think it means how vulnerable the server OS is.

> 5.1.3	Naming services in Case A
> 
> At this phase of IPv6 deployment, hosts in the unmanaged domain have
> access to DNS services over IPv4, through the existing gateway. DNS
> resolvers are supposed to serve AAAA records, even if they only
> implement IPv4; the local hosts should thus be able to obtain the
> IPv6 addresses of IPv6 only servers.
> 
> ==> s/are supposed to//
> ==> s/should thus be/are/ (are these really worth the conditionals..)

Very old resolvers don't support AAAA.

> 5.4	Case D, ISP stops providing native IPv4 connectivity
> 
> In this case the ISP is IPv6-only, so the gateway looses IPv4
> connectivity, and is faced with an IPv6-only service provider. The
> gateway itself is dual stack, and the unmanaged network includes
> IPv4 only, IPv6 only and dual stack hosts.
> 
> ==> no IPv4 connectivity to the customer, or no v4 at all (e.g. no
> possibility for ALG's, web caches, DNS / SMTP servers etc.).  Probably the
> former.

I think so.

> 3.2	Client applications
> 
> network and a server at a remote location. A typical example is
> accessing a web server from a client inside the managed network, or
> reading and sending e-mail with the help of a server outside the
> managed network.
> 
> ==> s/managed/unmanaged/g (whoops.. :-)

Fixed in -02.

> applications are often facilitated by a server outside the managed
> networks. Examples of a peer-to-peer application would be a video-
> 
> ==> s/managed/unmanaged/ (whoops :-)

Fixed in -02.

> representation of the IPv4 address of the server, either by sing a
> 
> ==> s/sing/using/

Fixed in -02.

We will fix the others in -03.

Thanks for reading the draft and commenting on it.

	rvdp