Re: unmanaged scope comments (fwd)

[Pekka Savola <pekkas@netcore.fi>]

On Wed, 20 Nov 2002, Ronald van der Pol wrote:
> > 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.

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

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

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

Perhaps this question should be raised at the v6ops meeting when 
discussing the scenarios document.  
 
> > 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?

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

At least around here, and I know many other places, where at least one IP 
address is provided to the end-user.
 
> > 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.

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

Current draft has moved around a bit and this doesn't even seem to exist 
anymore, so this is probably moot.
 
> > 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.

Right.  These have entirely different design restrictions on what services 
must be provided.
 
-- 
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