Please ignore. I was probably too tired to notice the incorrect "To" address while sending it.
The mail has now been sent to its correct destination. CP On Sun, 16 Nov 2003 20:51:22 +0530, "Chirayu Patel" <[EMAIL PROTECTED]> said: > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
