Subject: RE: Comments on unman-scenarios-03

From: "Christian Huitema" <[email-masked]>
Date: Mon, 17 Nov 2003 09:56:03 -0800

Chirayu,

Sorry, but your comments are coming too late. The draft already went
through last call (back in June). The purpose of version 03 was to take
into account some IESG comments. The high level issues you mentioned,
stacked gateways or static addresses, were discussed through the draft
progression and were considered somewhat marginal. Their absence in the
draft is intentional.

-- Christian Huitema

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Chirayu Patel
> Sent: Sunday, November 16, 2003 5:39 PM
> To: [email-masked]
> Subject: Comments on unman-scenarios-03
> 
> 
> Hello,
> 
> Few comments on the unman-scenarios-03 draft.
> 
> CP
> 
> 
> High-Level
> ----------
> 
> 1.
> 
> None of the cases consider a dual-stack gateway that is connected
> to the ISP.
> 
> #  [Host1]----------v
> #                 [Gateway]------[Gateway]------------[ISP]
> #   [Host2]----------^              |
> #                                   |
> #                                   |
> #   [Host3]-------------------------+
> 
> Internal gateways may be IPv4-only, or dual-stack or IPv6 only.
> 
> I think some general text should be mentioned about connectivity,
naming,
> and application support in hosts that are located behind an internal
> gateway (IPv4-only, dual, and IPv6-only) for each of the cases.
> 
> For example, in case C, if the network has an IPv4 only gateway, then
it
> might not be possible certain local applications on the hosts behind
> this gateway.
> 
>  2.
> 
> All hosts that have static (IPv6) addresses can host servers. With
that
> in mind, I think the text related to server applications in case A
should
> be modified.
> 
> The current text reads,
> 
> ,----
> |    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, which is likely to be present in
this
> |    case. Besides, server applications at present cater mostly to
IPv4
> |    clients; putting up an IPv6-only server is not very attractive.
> `----
> 
> As long as the IPv6 host has a static address, the ease/difficulty of
> providing DNS support will be similar to case B or C. The other
> assumption regarding attractiveness will not hold true if the global
> scenario is that the unmanaged network is late in getting IPv6
support,
> and the rest (or a large part) of the world is already using IPv6.
> 
> 
> Semi-editorial
> --------------
> 
>  3.
> 
> ,----
> |    Deploying servers usually requires providing each server with a
> |    stable DNS name, and associating a global IPv4 address with that
> |    name, whether the address be that of the server itself or that of
> |    the router acting as a firewall or NAT. Since updating DNS is a
> |    management task, it falls somewhat outside the scope of an
unmanaged
> |    network. On the other hand, it is also possible to use
out-of-band
> |    techniques (such as cut-and-paste into an instant message system)
to
> |    pass around the address of the target server.
> `----
> 
> I think for the purposes of this document, and the companion (eval)
> document, updating DNS should not be considered as a management task
> whose scope is outside the scope of an unmanaged network. In my
opinion
> the availability of stable addresses, and broadband will actually
> trigger the demand to simplify the infrastructure needed to host
servers
> in home networks.
> 
> I propose s/Since updating DNS is a management task, it falls somewhat
> outside the scope of an unmanaged network.//
> 
>  4.
> 
> ,----
> |    As we transition to IPv6, we must meet the requirements of the
> |    various applications, which we can summarize in the following
way:
> |    applications that used to work well with IPv4 should continue
> |    working well during the transition; it should be possible to use
> |    IPv6 to deploy new applications that are currently hard to deploy
in
> |    IPv4 networks; and the deployment of these IPv6 applications
should
> |    be simple and easy to manage, but the solutions should also be
> |    robust and secure.
> `----
> 
> Few requirements are missing:
> 
>   a) During the transition applications must work well with with both
>      IPv4 and IPv6 networks to ease application deployment.
> 
>   b) Interworking may have to be defined for applications that will
>      execute on IPv4-only networks, and IPv6-only networks. (I am
unable
>      to phrase this one properly). For example, a p2p application on a
>      IPv4 only network may want to interact with a peer on a IPv6
>      network. For this interworking technology, and gateways have to
be
>      developed.
> 
>  3.
> 
> ,----
> |    Client applications require global connectivity. In an IPv6
network,
> |    we would expect the client to use a global IPv6 address, which
will
> |    have to remain stable for the duration of the client-server
session.
> `----
> 
> The second sentence "In an IPv6 network..." seems out of place. This
> section is list requirements of client applications in home networks
> (independent of the network technology). The second sentence can
probably
> be replaced with:
> 
> "Client applications need a global address that will remain stable for
> the duration of the client-server session."
> 
>  4.
> 
> ,----
> |    Many servers try to look up a DNS name associated to the IP
address
> |    of the client. In an IPv4 network, this IP address will often be
> |    allocated by the Internet service provider to the gateway, and
the
> |    corresponding PTR record will be maintained by the ISP. In many
> |    cases, these PTR records are perfunctory, derived in an
algorithmic
> |    fashion from the IPv4 address; the main information that they
> |    contain is the domain name of the ISP. Whether or not an
equivalent
> |    function should be provided in an IPv6 network is unclear.
> `----
> 
> It might help to appreciate the last sentence better, if it is
mentioned
> that even though few servers do a reverse lookup, there are many IPv4
> ISP's that do not provide reverse lookup databases.
> 
>  5. Section 4.3
> 
> Naming requirements for P2P applications are not mentioned.
> 
>  6.
> 
> ,----
> |    Private conversations by one of the authors with developers of
peer-
> |    to-peer applications suggest that many would be willing to
consider
> |    an "IPv6-only" model if they can get two guarantees:
> |
> |    1) That there is no regression from IPv4, i.e. that all customers
> |       who could participate in a peer-to-peer application using IPv4
> |       can also be reached by IPv6.
> |
> |    2) That IPv6 provides a solution for at least some of their hard
> |       problems, e.g. enabling peers located behind an IPv4 NAT to
> |       participate in a peer-to-peer application.
> `----
> 
> This text can be removed/reworded. Point 1, is already covered in the
> requirement summary in beginning of section 4. Point 2, can be
reworded,
> and merged with the first paragraph in this section (Requirements of
> peer-to-
> peer applications).
> 
>  7. [DNSOPV6] has expired, and if a new version is not going to be
>     released, relevant parts of that draft should be moved to this
>     document. Probably section 5.2.2 should mention that if a DNS
server
>     is being deployed in the network then it should accessible over
both
>     IPv4, and IPv6.
> 
>  8.
> 
> ,----
> |    Network level translation poses similar problems: in practice,
> |    network level actions must be complemented by "application layer
> |    gateways" that will rewrite references to IP addresses in the
> |    protocol, and while these relays are not necessary for every
> |    application, they are necessary for enough applications to make
any
> |    sort of generalized translation quite problematic; hosts may need
to
> |    be parameterized to use the translation service; and designing
the
> |    right algorithm to decide when to translate DNS requests has
proven
> |    very difficult.
> `----
> 
> I don't quite follow "the right algorithm to decide when to translate
> DNS requests". Is there any reference, or has this issue been
discussed
> in the past?
> 
>  9.
> 
> ,----
> |    Not assuming translation services in the network appears to be
both
> |    more practical and more robust. If the market requirement for a
new
> |    device requires that it interact with both IPv4 and IPv6 hosts,
we
> |    may expect the manufacturers of these devices to program them
with a
> |    dual stack capability; in particular, we expect general purpose
> |    systems such as personal computers to be effectively dual-stack.
> `----
> 
> Instead of using the words "device", "device interaction with hosts",
> "client", and "server applications" should be used as this section
takls
> of these applications, The paragraph can be rephrased to :
> 
> "Not assuming translation services in the network appears to be both
more
> practical and more robust. If the market requirement for a new
> application requires that it interact with both IPv4 and IPv6 hosts,
we
> may expect the developers of these applications to program them with
> support for both IPv4, and IPv6. Hence, the devices that are expected
to
> run these applications will have to be dual-stack."
> 
> 10. Section 5.2.2
> 
> ,----
> |    In Case B, the upgraded gateway will act as an IPv6 router; it
> |    will...
> `----
> 
> Should it not be:
> 
> "In Case B, the upgraded gateway will act either as an IPv6 router, or
as
> a ND proxy [NDPROXY]; it will..."
> 
> 11.
> 
> ,----
> |     several solutions will be assessed in a companion memo [EVAL].
> `----
> 
>     -or-
> 
> ,----
> |     Possible solutions will be compared in the evaluation draft.
> `----
> 
> Such instances should be removed from the text, and the purpose of the
> [EVAL] document should be made clear in the Introduction.
> 
> 12. Section 5.2.2
> 
> It would not hurt, if it is mentioned that the the type of IPv6
> connectivity for the hosts is native.
> 
> 13.
> 
> ,----
> |     There are multiple solutions, including domain name delegation.
> `----
> 
> What are the other solutions?
> 
> 14.
> 
> ,----
> |    A delegation of some domain name is required in order to publish
the
> |    IPv6 addresses of servers in the DNS.
> `----
> 
> This point is suppossed to be different for case B, and case C. I am
> unable to see the difference. Both the cases require a domain name
> delegation.
> 
> 15.
> 
> ,----
> |    - the requirement that tunneling protocols used for IPv6 access
over
> |      IPv4 be designed for secure use
> `----
> 
> This requirement is more of a transition mechanism requirement, and
less
> of an application requirement. I also could not find where this
> requirement is discussed. The only thing I could find is a general
> requirement for all solutions to be secure, which is listed in section
> 16.
> 
> 17.
> 
> ,----
> |    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 think this one should be mentioned upfront in the Introduction
section
> as it will help to clarify the scope of the document.
> 
> Is the document mentioned in the last sentence published?
> 
> Editorial
> ---------
> 
> 18.
> 
> ,----
> |    There are some cases in which the "gateway" is replaced by a
layer-2
> |    bridge. In such deployments, the hosts have direct access to the
ISP
> |    service. In order to avoid lengthy developments, we will treat
these
> |    cases as if the gateway was not present, i.e. as if each host was
> |    connected directly to the ISP.
> `----
> 
> I am unsure if word developments is correctly used. Plus, the text
about
> connected directly to the ISP is repeated. I propose to rephrase the
> paragraph to:
> 
> "There are some cases in which the "gateway" is replaced by a layer-2
> bridge. In such deployments, the hosts have direct access to the ISP
> service, and the gateway is assumed to be absent."
> 
> 19. Modify the section titles so that the words start with upper case.
> 
> 20.
> 
> ,----
> |    The application requirements for IPv6 Unmanaged Networks fall
into
> |    three general categories: connectivity, naming, and security.
> |    Connectivity issues include the provision of IPv6 addresses and
> |    their quality: do hosts need global addresses, should these
> `----
> 
> s/The application requirements/The requirements related to
applications/
> 
> I was confused when I had initially read the first sentence. I could
not
> make out if the sentence meant requirements of the network, or the
> requirements of the application.
> 
>  4. Section 4.4
> 
> I am a bit lost...what does collateral effect mean? :-)
> 
>  5.
> 
> ,----
> |    In order to get some clarity, we distinguish three entities
involved
> |    in the transition of an unmanaged network: the ISP (possibly
> |    including ISP consumer premise equipment (CPE)), the home
gateway,
> |    and the hosts (computers and appliances). Each can support IPv4-
> |    only, both IPv4 and IPv6 or IPv6-only. That gives us 27
> |    possibilities.
> `----
> 
> Reword to
> 
> "In order to get some clarity, we distinguish three entities involved
in
> the transition of an unmanaged network: the ISP, the home gateway, and
> the hosts (computers and appliances). Each can support IPv4-only, both
> IPv4 and IPv6 or IPv6-only. This gives us 27 possibilities. Note, that
> ISP transition may also include the transition of the ISP provided
home
> gateway, aka, CPE (Customer Premise Equipment)."
> 
>  6.
> 
>    We describe the most important cases. We will assume that in all
cases
>    the hosts are a combination of IPv4-only, dual stack and (perhaps)
>    IPv6-
>    only hosts.
> 
> s/(perhaps)//
> 
>  7.
> 
> ,----
> |    In fact, we can consider three non-NAT variants: directly
connected
> |    host; gateway acting as a bridge; and gateway acting as a non-NAT
IP
> |    router.
> `----
> 
> s/In fact, we can consider three non-NAT variants:/There are three
types
>   of non-NAT variants:/
> 
>  8. Section names of 5.x should be made consistent with the actual
case
>     name. For example, section 5.1 should be renamed to "Case A,
gateway
>     without IPv6 support".
> 
>  9.
> 
> ,----
> |    There are two variations of this case, depending on the type of
> |    service implemented by the gateway. In many cases, the gateway is
a
> |    direct obstacle to the deployment of IPv6, but a gateway which is
> |    some form of bridge-mode CPE or which is a plain (neither
filtering
> |    nor NAT) router does not really fall into this category.
> `----
> 
> Rephrase. Just to make it a bit more clear.
> 
> "There are two variations of this case, depending on the type of
service
> implemented by the gateway. In many cases, the gateway is a direct
> obstacle to the deployment of IPv6. In other cases, the gateway is
some
> form of bridge-mode CPE or a plain (neither filtering nor NAT)
router."
> 
> 10.
> 
> ,----
> |    If the local gateway provides global IPv4 addresses to the local
> |    hosts, then these hosts can individually exercise the mechanisms
> |    described in case C, "IPv6 connectivity without provider
support."
> |    If the local gateway implements a NAT function, another type of
> |    mechanism is needed. The mechanism to provide connectivity to
peers
> |    behind NAT should be easy to deploy, and light weight; it will
have
> |    to involve tunneling over a protocol that can easily traverse
NAT,
> |    either TCP or preferably UDP, as tunneling over TCP can result in
> |    poor performances in case of time-outs and retransmission. If
> |    servers are needed, these servers will in practice have to be
> |    deployed as part of the "support infrastructure" for the peer-to-
> |    peer network or for an IPv6-based service; economic reality
implies
> |    that the cost of running these servers should be as low as
possible.
> `----
> 
> The lines starting from "If servers are needed..." should be moved to
> 10.1.1. I am not sure what they are suppossed to convey. Maybe they
can
>         be removed.
> 
> 11.
> 
> ,----
> |    problems: first, one must develop relays for all applications;
> |    second, one must develop a management infrastructure to provision
> |    the host with the addresses of the relays; in addition, the
> |    application may have to be modified if one wants to use the relay
> `----
> 
> s/; in addition/, and third/
> 
> 12.
> 
> s/peer to peer/peer-to-peer/
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Chirayu Patel" <[email-masked]>
Date: Mon, 17 Nov 2003 23:42:12 +0530

Oh well! :-( I really wish there was some field within the draft to
indicate its status.

Anyways, I had read unman-scenarios to get to the next one (unmaneval).
Comments on that one are typed out...but it is too late in the night.
Will send them out tomorrow.

CP

---

From: Pekka Savola <[email-masked]>
Date: Mon, 17 Nov 2003 21:28:06 +0200 (EET)

> progression and were considered somewhat marginal. Their absence in the

Some of the few editorial nits can probably be fixed at AUTH48, but unless 
you, Chirayu, think that there have been really significant omissions that 
we should pull the draft back from the IESG's approval, please state 
those.

On a more happy note, please ensure that the similar issues have been 
proposerly addressed in the analysis document.

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