Subject: unmanaged scope comments (fwd)

From: Pekka Savola <[email-masked]>
Date: Mon, 18 Nov 2002 00:07:06 +0200 (EET)

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

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.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---------- Forwarded message ----------
Date: Thu, 19 Sep 2002 18:34:23 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: [email-masked]
Subject: unmanaged scope comments

Larger issues: 

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
  b) static
      - ^
      - ^
 2. private addresses: NAT by ISP (or outside of your control) [otherwise
one of cases above]
      - dynamic
      - static

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.

3)

4.2	Requirements of client applications
[...]
maintaining the privacy of the client. Many potential users of IPv6
observe that the current NAT configuration provides some level of
privacy: all communications to outside servers appear to come from
the single IPv4 address of the NAT; the source IPv4 address does not
identify a specific host inside the unmanaged network ..

==> .. or even a specific host in the ISP.  IMO it's usually a non-issue,
particularly in unmanaged case, whether someone can identify which node in
a sparsely populated subnet is which.

4) Triggered by sect 4.3 and 4.4, but it's more generic than that; I think
the draft needs to consider differences wrt. static/dynamic
addresses/prefixes.  In particular, privacy, server address and generally
DNS issues come to mind.

5) 

The case where the ISP is IPv6 capable, but the gateway is not is
similar to case A.

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.

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

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.
==> In case A, clients don't necessarily need to be behind a NAT.

7) backward/upward compatibility; I brought this up in the interim meeting. 
IMO I don't see it as a hard requirement to be able to be able to perform
v4only <-> v6only conversions.  This depends quite a bit on what our "dual
stack" deployment strategy is: whether we encourage vendors (e.g. LCNA type
applications) to ship v6-only stacks or dual-stacks.

8) A comment:

-- I think that there is a case to be made that using translation
tools boosts the previously mentioned network effect and makes it
work in our favor; the somewhat crippled nature of the translation
tools is in fact also a good thing, because it gives people an
incentive to throw them away once they realize that they are broken.
I realize that this is heresy, so be it. --

==> No I don't agree with the last statement: this gives folks only an
incentive to enhance and tweak these features, not fix them *properly*. 
Think NAT ALGs...

Semi-editorial:

nat/firewall with that name. Since updating DNS is a management
task, it somewhat falls outside the scope of an unmanaged network.

==> management, yes, but it's often automatic.

A peer to peer session typically starts by
an exchange of synchronization messages through the rendezvous
servers, during which the peers exchange the addresses that will be
used for the session.

==> not knowing better these protocols, I'm only guessing, but some of these
messages could be done e.g. to initiate NAT, and thus be at least partially
unnecessary with IPv6.

There are multiple aspects to the security of peer-to-peer
applications, many of which relate to the security of the rendezvous
system. 

==> I'm not sure which threats you refer to; the one I can think of is some
kind of information disclosure.  But I'm more afraid of the (programming) 
security of p2p apps myself.

4.4	Requirements of server applications
The DNS entries for the server will have to be updated, preferably
in real time, if the server's address changes. In practice, updating
the DNS is slow, which implies that server applications will have a

==> The slowness of DNS is debatable, I think.  TTL can be tuned if
necessary.

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?

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

presence of translation or port mapping services; there is also not
much of a case for letting local IPv4 servers publish their service
on the IPv6 Internet.

==> I agree!  These should be dual-stacked if they're important.

To enable this scenario, the gateway need to use a mechanism obtain
a global address prefix from the ISP, and advertise this address
prefix to the hosts in the unmanaged network; several solutions will
be assessed in a companion memo [EVAL].

==> and in the degenate case...?

5.2.3	Naming services in Case B

[...]. Currently, IPv4 only hosts
discover the IPv4 address of the local DNS server using DHCP; there
must be a way for IPv6 only hosts to discover the IPv6 address of
the DNS server.

==> s/discover/usually discover/

Generic issue: I think that perhaps case B and case C could be reversed; I
find it more probable that ISP is the last party of the three to offer v6
service.

5.3.2	Addresses and connectivity in Case C

There are two ways to bring immediate IPv6 connectivity on top of an
IPv4 only infrastructure: automatic tunnels provided by the [6TO4]
technology, or configured tunnels. Both technologies have advantages
and limitations, which will be studied in a companion document.

==> + mechanisms if gateway does not have global addresses.

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.

Editorial:

s/IPv6 only/IPv6-only/ ?
s/IPv4 only/IPv4-only/ ?

2	Topology
(ISP)connection. Several hosts are connected to the subnet:

==> s/are/may be/

or may not perform NAT and firewall function. A key point of this
==> s/function/functions/

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

3.3	Peer-to-peer applications

There are two kinds of peer-to-peer applications, the "local peer-
to-peer" that only involve hosts on the unmanaged network, and the

s/on the unmanaged network/in the unmanaged network/ (lots of other places;
I'm not sure which one is correct, but 'in' sounds better to my ear at
least)

well identified peers outside the unmanaged network. These

==> s/well identified/well-identified/ ?

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 :-)
==> s/networks/network/

3.4	Server applications

==> I think the order should be changed: Server before Peer-to-peer, as peer
to peer is IMO the most generic case.
                                                          requires
some special programming of the NAT or firewall. When the NAT only
publishes a small number of global IP addresses and relies on "port

==> s/requires/require/
==> s/publishes/maps to/ (or something else, publishes sounds funny)?

nat/firewall with that name. Since updating DNS is a management
task, it somewhat falls outside the scope of an unmanaged network.

==> s/nat/NAT/

4.2	Requirements of client applications
An important security issues with client applications is,

==> s/issues/issue/
==> s/is,/is/

4.3	Requirements of peer-to-peer applications
Peer-to-peer applications require global connectivity. In an IPv6
network, we would expect the peers to use a global IPv6 address,
which will have to remain stable for the duration of the peer-to-
peer between client and server.

==> s/peer/peer session/
==> "client and server" is a bit funny wording in P-2-P case.. :-)

to deploy, and light weight; it will have to involve tunneling over

==> s/light weight/light-weight/ (not sure..?)

5.2.1	Application support in Case B

We expect the unmanaged network to include three kinds of hosts:
IPv4 only, IPv6 only, and dual stack. 

==> soften the wording a bit: not every unmanaged network need to include
all three.

IPv4 only hosts use the services a brand new IPv6 only printer.

==> s/services/services, like/

To enable this scenario, the gateway need to use a mechanism obtain

==> s/need/needs/, s/obtain/to obtain/

not.  The gateway has been upgraded and offers both IPv4 and IPv6
connectivity the hosts. It cannot rely on the ISP for IPv6

==> s/connectivity/connectivity to/

connectivity, because the ISP does not offer ISP connectivity yet.

==> s/offer ISP/offer IPv6/

representation of the IPv4 address of the server, either by sing a

==> s/sing/using/

--
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Ronald van der Pol <[email-masked]>
Date: Wed, 20 Nov 2002 03:22:43 +0100

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

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

>       - enough addresses for every node

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

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

> ISATAP to their v6-enabled network.

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

> e.g. bridged ATM encapsulation in xDSL).

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

> too often to be really updateable or writable in DNS.  This does not need to

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.

> ==> does 'correctness of the server' refer to the server application?

I think it means how vulnerable the server OS is.

> ==> s/should thus be/are/ (are these really worth the conditionals..)

Very old resolvers don't support AAAA.

> possibility for ALG's, web caches, DNS / SMTP servers etc.).  Probably the

I think so.

> ==> s/managed/unmanaged/g (whoops.. :-)

Fixed in -02.

> ==> s/managed/unmanaged/ (whoops :-)

Fixed in -02.

> representation of the IPv4 address of the server, either by sing a

Fixed in -02.

We will fix the others in -03.

Thanks for reading the draft and commenting on it.

	rvdp

---

From: Pekka Savola <[email-masked]>
Date: Wed, 20 Nov 2002 04:56:22 +0200 (EET)

> when you transition to v6.

Naturally, it should not get any worse.

But depending on whether the boxes that can (or need) to support v6 can be 
upgraded or not sets some requirements to consider.

For example, consider the following connectivity methods:

a) ISP -- DSL modem w/ bridging -->

and

b) ISP -- DSL modem w/ routing -->

and what's connected behind that:

 1) hub/switch
 2) some cheapo router
 3) some PC (e.g. a windows box with connection sharing, BSD router, etc.)
 4) directly connected PC

Now, in case a) you never have to upgrade the DSL modem -- you will only 
need to care about what you connect to it.  This is only problematic in 
case 2) above.  Of course this will break if the ISP doesn't even offer 
public addresses in the DHCP.

On the other hand, in case b), you will basically always have to care 
about upgrading the DSL box -- and even if you get a public IP address, it 
will get wasted in the DSL  modem, as it (usually) offers only private 
connectivity to the LAN.
 
> not specific to unmanaged networks. It could go in a general BCP.

Agreed that it isn't special.

People do use v6 on a daily basis, but the problem is that the mess is so 
big and remote, it just can't be fixed because those causing the problems 
apparently either aren't sufferiong from the probles or aren't using v6 on 
a daily basis.
 
> "the ISP may or may not provide *native* IPv6"

That could be changed, yes, but I don't think it fixes the real issue that 
if gateway hasn't been upgraded, you may still be able to use v6 just fine 
(just not native all the way to the ISP but who cares?).
 
> Yes, should we discuss bridged networks? Are they widely deployed or are

Perhaps this question should be raised at the v6ops meeting when 
discussing the scenarios document.  
 
> How would you do this unmanaged?

It's difficult to say, depends on what was meant with the term "DNS 
support" here.

If there is just one service, the mapping need to be too difficult (just 
1:1).
 
> majority, I don't think we should complicate the draft even further.

At least around here, and I know many other places, where at least one IP 
address is provided to the end-user.
 
> I think it means how vulnerable the server OS is.

reword :-)
 
> Very old resolvers don't support AAAA.

Current draft has moved around a bit and this doesn't even seem to exist 
anymore, so this is probably moot.
 
> > possibility for ALG's, web caches, DNS / SMTP servers etc.).  Probably the

Right.  These have entirely different design restrictions on what services 
must be provided.