[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D ACTION:draft-ietf-v6ops-unman-scenarios-01.txt
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)
On Fri, 6 Jun 2003, Margaret Wasserman wrote:
> 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
>
>
>
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings