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 PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
