Re: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt

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

On Sat, Mar 01, 2003 at 16:32:03 +0200, Pekka Savola wrote:

> The biggest (potential) issue:
> 
> ==> the document goes beyond describing the current IPv4 deployments in
> several places, like 5.2.1 and 5.4.1; personally, these have typically
> been "rough solution scoping" -type approaches, and suggestions seem
> pretty good to me, at least.  
> 
> However, they may or may not be appropriate as is.
> 
> Is this a sensible approach?  Does someone see a process issue here?  
> It's (on a higher level) fine by me, at least.

I think you are right that ideally the scenario drafts should not do
analyses. But I think making some choices to limit the analysis draft
is not too bad.

> (one approach might be tone down the language in these a bit e.g. in:
> 
>  Our analysis concludes that a tunnel service will be vastly preferable.
> 
> change to:
> 
>  Our analysis concludes that tunnel service seems to be vastly preferable.

I guess we could do that.

> A particular thing I note that multiple-subnet case seems to be 
> out of scope, or that's the impression I get based on the first paragraph.

We have been discussing multiple-subnet cases internally, especially an
802.11b router connected to a home LAN behind a SOHO router to the ISP.
In the IPv4 case this usually is a NAT behind a NAT :-(

>    Deploying servers usually requires providing the servers with a
>    stable DNS name, and associating the global IPv4 address of the
>    nat/firewall with that name.
> 
> ==> associating with the address of _NAT/firewall_?  If there is NAT, 
> that's something that has to be done, yes.  
> 
> ==> So, if there is no NAT, this needs rewording.

True.

> 4.2.1   Privacy requirement of client applications
> 
> ==> this sub-section should be preceeded by a short paragraph describing 
> why only "privacy" part of "security" was taken into consideration.

It said security first, but than some in the design team noted that it
was more about privacy than security :-)

> ==> bigger issue: isn't this text applicable to all cases A-D?  Could be 
> placed somewhere else in the document, maybe?

It already is. Section 4 is not specific to one scenario, but to all.

>    Randomization of the host identifier does however provide benefits.
>    First, if some of the hosts in the unmanaged network are mobile, the
>    randomization destroys any correlation between the addresses used at
>    various locations: the addresses alone could not be used to
>    determine whether a given connection originates from the same laptop
>    moving from work to home, or used on the road.
> 
> ==> this seems rather an issue for mobile computers, not specific for 
> unmanaged networks.

True.

> 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
>    better chance of being deployed if the IPv6 addresses remain stable
>    for a long period.
> [...]
> 
> ==> please consider the context here.  Personally, as one who has services
> on his home PC (acting also as a router), like SSH access, I don't feel
> absolute smoothness is a requirement.  A nice thing to have, surely, but
> not a requirement.  Unmanaged network is *NOT* the place to run critical
> services, especially if one has a NAT to traverse -- I'm sure we all agree
> on that.

I don't think it's about smoothness, but about stability. You want the
server to have a stable (over a long time) IPv6 address. And I think
services are important for unmanaged networks. Think about all kinds of
IPv6 appliances in a home that one can reach from anywhere.

>    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.
> 
> ==> "DNS support" should IMO be clarified or elaborated.  This is 
> actually not the case, AFAICS.  Of course, publishing a DNS update is a 
> problem, but the root cause seems to be configuring the NAT to forward the 
> requests, not the DNS support itself.

OK, I guess you can read it in different ways. But is says "is difficult
to engineer" and I think that is the main point.

> 5.2.2   Addresses and connectivity in Case B
> 
>    In Case B, the upgraded gateway will behave as an IPv6 router; it
>    will continue providing the IPv4 connectivity of a non-upgraded NAT.
>    Nodes in the local network will obtain:
> 
> (same in 5.3.2)
> 
> ==> the document assumes that in case B, the NAT is being used.  That's 
> not necessarily the case.

True, but in the scenario drafts we try to describe the most common cases.
And unfortunatly, it seems NATs are very common.

> ==> (editorial: "connectivity of a non-upgraded NAT" needs rewording in 
> any case -- I can only try to guess what it means)

OK.

> Any interaction between
>    hosts in the unmanaged network and IPv4 hosts on the Internet will
>    require the provision of some inter-protocol services by the ISP.
> 
> ==> (and later, even more so) -- one should perhaps add an informative 
> reference to the ISP scenarios document.  In a way, unmanaged team gives a 
> suggestion for the long-term ISP transition plan, and that should be more 
> explicit in the text in some way.

OK.

Thanks for your comments.

	rvdp