Subject: RE: I-D ACTION:draft-ietf-v6ops-unman-scenarios-01.txt

From: Margaret Wasserman <[email-masked]>
Date: Fri, 06 Jun 2003 10:12:41 -0400

Hi All,

Please review the changes to this document, and let us know if all
of your last call issues were adequately resolved.  If there are no
remaining issues, we hope to forward this document to the IESG by
the middle of next week.

Thanks,
Margaret

At 02:44 PM 6/5/2003 -0700, Christian Huitema wrote:
>The draft "draft-ietf-v6ops-uman-scenarios-01.txt" into account the
>comments received during the V6OPS WG last call for
>draft-ietf-v6ops-uman-scenarios-00.txt. The authors believe that this
>document addresses the last call comments. A list of these comments and
>the way they were addressed is available at:
>
>         http://www.huitema.net/ipv6/Unman-Scenarios-Issues.htm
>
>The main changes fall in three categories:
>
>1) Change the topology section to explain exactly why we did not
>consider the multiple subnet case (i.e., with today's technology, such
>networks are not unmanaged);
>
>2) Change several of the case description scenarios to remove the
>more-or-less implicit assumption that there is always a NAT in IPv4
>deployments;
>
>3) Fix a number of editorial issues, notably the abstract, the
>introduction, the wording of references to DNS issues, and a split of
>references between normative and informative.
>
>-- Christian Huitema

---

From: Fred Templin <[email-masked]>
Date: Fri, 06 Jun 2003 08:44:40 -0700

Margaret,

Not wanting to hold up process, but I'm afraid I do see one item
in the changes that somehow escaped my attention earlier. In the
abstract, the following new text appears:

  "The scenarios are specific to single link subnet"

In this context, the phrase "single link subnet" seems too restrictive
by its inclusion of the word "link". Everywhere else in the document,
we see the phrase expressed as "single subnet", and I do agree with
this usage. Suggest changing the phrase in the abstract to:

  "The scenarios are specific to a single subnet"

While I'm on the subject, there were a few minor editorial comments:

1) In section 5.2.2, first sentence of the second paragraph, the phrase
    "NAT will not be in use" appears twice.

2) Section 5.3, end of second sentence should be: "to hosts.", not
    "the hosts."

3) Section 5.4.2, first sentence of the second paragraph, change:
    "dual stack host" to "dual stack hosts".

Fred
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Wed, 11 Jun 2003 13:37:58 +0300 (EEST)

Hi,

A few issues that I came across while quick-reading through it.  I'm not 
really confortable with the separation to different cases, but by a bit 
more text I think it would be of sufficient clarity.

substantial:
------------

I fear that the unusual cases have not been sufficiently addressed yet; a
mention has been added in section 5, but *at least* the same thing should be
repeated when going through the cases, so that the reader will not forget
the case also includes some (perhaps non-obvious) cases.  In the end, I
believe most of these issues stem from the definition of "Gateway".  Maybe
separation to more cases would have been better.. Oh well.

Let's see:

5.2	Case B, IPv6 connectivity with provider support
   
   In this case the ISP and gateway are both dual stack. The gateway
   can use native IPv6 connectivity to the ISP and can use an IPv6  
   prefix allocated by the ISP.

==> add discussion on:
 - bridge mode CPE's and dual-stack ISP
( - route mode dual stack CPE's which give private IPv4 addresses to hosts 
is not that interesting IMO)

Say, for example:

   In this case the ISP and gateway are both dual stack. The gateway
   can use native IPv6 connectivity to the ISP and can use an IPv6
   prefix allocated by the ISP.  Please note that if the gateway does not
   need to be aware of IPv6 if it is operating in the bridging mode.

(IMO that wording is a bit bad but gives the impression..)

5.3	Case C, IPv6 connectivity without provider support
   
   In this case the gateway is dual stack, but the ISP is not.  The
   gateway has been upgraded and offers both IPv4 and IPv6 connectivity
   the hosts. It cannot rely on the ISP for IPv6 connectivity, because 
   the ISP does not offer ISP connectivity yet.

==> add discussion on:
 - bridged CPE while the customer does not provide IPv6 support
 - (routed CPE w/o IPv6 support + global addresses)

Say, for example:

   In this case the gateway is dual stack, but the ISP is not.  The
   gateway has been upgraded and offers both IPv4 and IPv6 connectivity
   the hosts. It cannot rely on the ISP for IPv6 connectivity, because
   the ISP does not offer ISP connectivity yet.

   Please note that
   when the gateway is operating in the bridging mode, it cannot
   effectively function as a dual-stack gateway: the hosts in the unmanaged
   network, often using global IPv4 addresses, will have to obtain IPv6
   connectivity directly

(A bit bad but again, gives the impression..)

   The upgraded gateway will behave as an IPv6 router; it will continue

==> note that "router" may not be applicable when bridging is being used..

5.4     Case D, ISP stops providing native IPv4 connectivity
   
   In this case the ISP is IPv6-only, so the gateway loses 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. 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.

==> bridging considerations..?  Replace e.g. with:

   In this case the ISP is IPv6-only, so the gateway loses 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. 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.

   In the case that the gateway is operating in the bridging mode,
   it cannot provide any IP-level services such as being an 
   IPv4-over-IPv6 tunnel endpoint, or acting as a recursive DNS name server.

(or something to that effect.)

semi-substantial/editorial:
---------------------------

   Between the subnet and the ISP access link is a gateway, which may
   or may not perform NAT and firewall function. A key point of this
   configuration is that the gateway is typically not "managed". In
   most cases, it is a simple "appliance", which incorporates some
   static policies. However, there are many cases in which the gateway
   is procured and configured by the ISP, and there are also some
   common cases in which we find two gateways back to back, one managed
   by the ISP and the other added by the owner of the unmanaged
   network.

==> reword and add considerations for bridging operation; maybe like:

   Between the subnet and the ISP access link is a gateway, which may
   or may not perform NAT and firewall function. A key point of this
   configuration is that the gateway is typically not "managed". In
   most cases, it is a simple "appliance", which incorporates some
   static policies.

   However, there are many cases in which the gateway
   is procured and configured by the ISP, and there are also some
   common cases in which we find two gateways back to back, one managed
   by the ISP and the other added by the owner of the unmanaged
   network.  Gateways may also function in a bridging mode, making them
   invisible in the IP layer.

....

   corresponds to a home or small office network. The scenarios are
   specific to single link subnet, and are defined in terms of IP  
   connectivity supported by the home gateway and the ISP. We first   

==> it might be appropriate to reword "home gateway", because homes are 
not the only targets here..
==> same in the beginning of section 5

   Local applications typically use ad hoc naming systems. Many of
   these systems are proprietary; an example of a standard system is  
   the service location protocol (SLP).

==> is the adhoc naming systems really true?  I mean, I certainly 
use DNS at home, but I'm not sure if my home is a typical unmanaged network
:-).

   Randomization of the addresses is not sufficient to guarantee
   privacy. Usage can be tracked by a variety of other means, from
   application level "cookies" to complex techniques involving data
   mining and traffic analysis. However, just because privacy can be
   breached by other means is not a sufficient reason to enable
   additional tracking through IPv6 addresses.

==> I have hard time parsing the last sentence?  What does it mean, 
really?  "enable additional tracking through IPv6 addresses"?  Does this
refer to all-out use of RFC3041 or something more?  

   Randomization of the host identifier has some cost: the address    
   management in hosts is more complex for the hosts and the gateway  
   may have to maintain a larger cache of neighbor addresses; however,
   experience from existing implementation shows that these costs are
   not overwhelming. Given the limited benefits, it would be
   unreasonable to require that all hosts use privacy addresses;
   however, given the limited costs, it is reasonable to require that  
   all unmanaged networks allow use of privacy addresses by those hosts
   that choose to do so.

==> Also note that this adds a cost if reverse DNS is used (which is written
down as a requirement at least under case D).

   similarly, the case in which the CPE is a router but is not a NAT
   maps either to case B or case C depending on what the    CPE router
   supports.

==> replace with:

   similarly, the case in which the CPE is a router but is not a NAT   
   typically maps  to case C; when CPE is dual stack, it doesn't 
   really matter whether IPv4 addresses used are private or public.

(or even omit after ';')

                                                   We also observe that 
   providing both IPv4 and IPv6 connectivity in an unmanaged network is
   not particularly difficult: we have a fair amount of experience  
   using IPv4 in unmanaged networks in parallel with other protocols
   such as, for example, IPX.

==> this is a bit dubious argument, because such protocols (IPX, NetBEUI) 
are not routed, but IPv4/IPv6 is.

6       Security Considerations

   The security solutions currently used in IPv4 networks include a   
   combination of firewall functions in the gateway, authentication and
   authorization functions in the applications, encryption and
   authentication services provides by IP security, Transport Layer  
   Security and application specific services, and host-based security
   products such as anti-virus software, and host firewalls. The
   applicability of these tools in IPv6 unmanaged networks will be
   studied in a companion document.

==> I'm not sure if this is good enough, may come against some resistance..
at least, something concrete must be available before the Solutions document
can be pushed to the IESG. k to keep it as is for now.

editorial:
----------

   Between the subnet and the ISP access link is a gateway, which may
   or may not perform NAT and firewall function. A key point of this 

==> s/function/functions/ (?)

   these systems are proprietary; an example of a standard system is
   the service location protocol (SLP).

==> add an informative reference here?

   manages a static IPv4 address; in both case, the IPv4 address or the

==> s/case/cases/

                     Many of these systems are proprietary; an example
   of a standard system is the session invitation protocol (SIP)

==> add informative reference to some SIP document?

   In order to get some clarity, we distinguish three entities involved

==> split from beginning of this sentence to a separate paragraph?

   maps either to case B or case C depending on what the    CPE router 

==> s/the    CPE /the CPE/

   relays such as HTTP proxies, or by network level services such as   
   NAT-PT. Application relays pose several operational problems: first,
   
==> add informational ref to NAT-PT.

   In some networks, NAT will not be in use and the local hosts will
   actually obtain global IPv4 addresses NAT will not be in use. We

==> s/NAT will not be in use// (the latter one)

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