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

[Pekka Savola <pekkas@netcore.fi>]

Commenting only to left-overs..

On Mon, 3 Mar 2003, Ronald van der Pol wrote:
> > 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 :-(

The best in this case might be to deploy the 801.11b router to act as a 
bridge.

But in any case, the scenarios document should be clearer on what is 
considered "in scope" for the unmanaged networks.
 
> > 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 :-)

Yes, I agree it's better to have a title corresponding to the text, but 
even better would be having multiple titles or justification why other 
parts of security weren't elaborated at that length.
 
> > ==> 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.

Oh ok, missed that.

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

Yes, I very much like to see IPv6 appliances and connectivity in place.

What I was trying to get at with the comment was that the so-called 
"connection survivability" or "DNS with zero TTL" should not be a problem 
in the unmanaged networks.

It's nice to have a stable IPv6 address, but one can survive with a 
downtime of a few hours, even a day (e.g. a delay in updating the DNS, DNS 
record lifetimes) -- which might not be acceptable in e.g. enterprise 
networks.
 
> >    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.

To me "difficult to engineer" doesn't really tell much, because I want to 
see some answer to the "why is it difficult to engineer?" as the answer is 
not obvious (or different people have different opinions on why exactly 
it's difficult).
 
> > 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.

In some places, they are; in some others, they might not be.  Unless it's 
very painful, I'd try to cover both cases at least in some detail (so that 
folks who are *not* harmed by NAT's at that particular place don't throw 
the scenarios document out of the window as irrelevant).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings