A working group last call was issued on the draft-00. The last call generated a set of comments. Pekka Savola and Chris Fischer provided a set of editing corrections, which will be incorporated in draft-01. Pekka, Chris, Erik Nordmark, Kurt Erik Lindqvist, Francis Dupont and Alain Durand also raised some non-editing issues, which are summarized in the following table. These issues have been corrected in the proposed new draft.
The resolved issues are:
|
Issue |
Title |
Author |
Date |
Status |
|
Pekka Savola |
3/1/03 |
Added text |
||
|
Pekka Savola |
3/1/03 |
Change accepted. |
||
|
Pekka Savola |
3/1/03 |
Rejected |
||
|
Pekka Savola |
3/1/03 |
Rejected. (Already resolved) |
||
|
Pekka Savola |
3/1/03 |
Added text |
||
|
Pekka Savola |
3/1/03 |
Added text |
||
|
Pekka Savola |
3/1/03 |
Change accepted. |
||
|
Pekka Savola |
3/1/03 |
Change accepted. |
||
|
Pekka Savola |
3/1/03 |
Rejected |
||
|
Pekka Savola |
3/1/03 |
Added text. |
||
|
Pekka Savola |
3/1/03 |
Added text |
||
|
Pekka Savola |
3/1/03 |
Added references |
||
|
Pekka Savola |
3/1/03 |
Change accepted. |
||
|
Pekka Savola |
3/1/03 |
Added text. |
||
|
Pekka Savola |
3/1/03 |
Fixed as part of resolving Q.14 |
||
|
Pekka Savola |
3/1/03 |
Added text |
||
|
Kurt Erik Lindqvist |
3/9/03 |
Change accepted. |
||
|
Chris Fischer |
3/10/03 |
Rejected |
||
|
Francis Dupont |
3/10/03 |
Added text |
||
|
Alain Durant |
3/10/03 |
Rejected |
||
|
Erik Nordmark |
3/19/03 |
Added text |
||
|
Erik Nordmark |
3/19/03 |
Added text. |
||
|
Erik Nordmark |
3/19/03 |
Minor change accepted |
A detailed description of the issues follows.
On 3/1/03 Pekka Savola wrote:
The document goes beyond describing the current IPv4 deployments in several places, like 5.2.1 and 5.4.1; personally, these have typically been "rough solution scoping" -type approaches, and suggestions seem pretty good to me, at least.
However, they may or may not be appropriate as is.
Is this a sensible approach? Does someone see a process issue here?
It's (on a higher level) fine by me, at least.
On 3/3/3, Ronald van der Pol replied:
I think you are right that ideally the scenario drafts should not do analyses. But I think making some choices to limit the analysis draft is not too bad.
Wed 4/23/2003 7:52 AM: I agree with "Proposed text".
(one approach might be tone down the language in these a bit e.g. in:
Our analysis concludes that a tunnel service will be vastly preferable.
change to:
Our analysis concludes that tunnel service seems to be vastly preferable.
Adopted the proposed language.
On 3/1/03 Pekka Savola wrote:
This section (2, topology) somewhat defines the context of the unmanaged network: should there be an explicit definition of it for the purposes of this doc, and the solutions document (might not be easy)?
A particular thing I note that multiple-subnet case seems to be out of scope, or that's the impression I get based on the first paragraph.
On 3/3/3, Ronald van der Pol replied:
We have been discussing multiple-subnet cases internally, especially an 802.11b router connected to a home LAN behind a SOHO router to the ISP. In the IPv4 case this usually is a NAT behind a NAT :-(
On 3/4/3, Christian Huitema continued:
The issue was debated in the working group, in particular during the WG meeting in Atlanta. There was a very strong consensus to restrict the scope of our work to "single link subnets". I don't believe it is appropriate to revisit that decision right now.
On 3/6/3, Jim Bound replied:
I don't agree with single link subnet. This is not cool and implies I use bridges in my house. In fact a colleague is now looking into UPnP to verify it is not stating this as we received rumor this was potential there too. People will run routers in their homes and SOHO's not only bridges with single subnet. That case will happen and we are not covering it.
But the point is we did agree. So what do we do now? Is it ok to revisit? The reason for a last call is to catch things we may have missed. The case can be made. But then how is that resolved. Do we never revisit anything? This is quite a limitation for sure in uman IMO. I think it is not wise limitation.
On 3/7/3, Ronald van der Pol replied:
You seem to be quite confident about that. Could you explain why you think multiple subnets will arrive in SOHOs? I'm not saying I don't agree with you. I just would like to know the scenarios where multiple subnets are needed. And when they are needed. I think we have already spent too much time on the scenario/analysis drafts. We should not delay any longer when it is not absolutely necessary.
Another question is whether v6ops should pick this up. Maybe zerouter (if that is going to be a WG) is a better place and we need to make sure they cover IPv6, unmanaged networks and SOHOs too.
On 3/7/3, Olaf Bonness replied:
from my point of view it's fairly obvious to have different subnets within my soho environment for instance one for every room I have or besides that when I want to use parts of my home (network) for professional reasons and want to separate this from my normal / private life.
On 3/7/3, Ronald van der Pol replied:
Yes, but I would like to know why it is fairly obvious. Is it because you want to use different ACLs on the different subnets? (ACLs and unmanaged networks don't fit well together :-) Is it because they use different technologies with different MTUs. Something else?
On 3/6/3, Jim Bound replied:
First and foremost it is a "choice" we should permit. I personally think bridges were a bad idea for networks back in the late 80's, and I don't believe extended LANs are acceptable, being inherently evil wearing my network computer scientist hat. That being said, in a home you have one subnet in the basement, one in the 1st level, and then one in next level of the home. Each with its own applications for that subnet for personal and household appliances. If I want to access other floors one can, but over a router, and one does not want to see the traffic for many reasons on the other subnets. In SOHO this can be a clear division of work like the Dentist Office. The Dentist work is using machinery and robotics on one subnet, and the office admin is doing accounting on another subnet, and common applications are running in the closet of the office in a server accessible to both, and where ingress/egress end points are to the public Internet. Each of these networks do not want others on their subnet and it could be for security reasons too. Admin at front office hates patient that comes in and turns up the speed on the Dentist's drill when the patient begins treatment :---)
As far as discussion. I asked the chairs the question. Until they tell us to stop discussion I intend to respond. Respectfully to that question.
If that logic (turning the work to zerouter) is true then the entire spec should move to zeroconf. I think that is not a good idea.
On 3/7/3, Christian Huitema replied:
There is no question that there may be a technical interest in having multiple subnets in a home network. However, there is also no question that we cannot provide "unmanaged multi-subnet networks" with today's technology. This is pretty much what settled the issue in the discussion group: multi-subnet networks, today, are managed. The UPNP architecture committee came pretty much to the same conclusion: structured networks in the home may be desirable, but are not practical today; bridges provide a reasonable alternative.
Not that I like this state of affairs. In fact, Dave Thaler and I submitted a draft to the IPv6 WG that addresses the issue (draft-ietf-ipv6-multilink-subnets-00.txt). I believe we need something like that in practice, as we are finding practical deployment of "cascaded NATs" in some home networks today, and that really breaks a number of applications.
But, well, this was the group's consensus.
On 3/7/3, Jim Bound conceded:
Excellent point. No way can we do unmanaged with multiple subnets.
Kills it for me. Move the draft to IESG review Margaret is my input before someone else opens another can of worms or pandaora's box. We must learn to ship our work expediently and quickly around here. The uman team has done the work, we have discussed it, it is a well written draft, and if the IESG in their infinite wisdom makes this PS any warts can be fixed after PS.
Thanks Christian I thought it was correct but in the discussion I missed the obvious and thanks for pointing that out to me indirectly.
Added the following text at the end of section 2:
Our definition of unmanaged networks explicitly exclude networks composed of multiple subnets. We will readily admit that some home networks and some small business networks contain multiple subnets, but in the current state of the technology these multiple subnet networks are not “unmanaged”: some competent administrator has to explicitly configure the routers. We will thus concentrate on single subnet networks, where no such competent operator is expected.
On 3/1/03 Pekka Savola wrote:
4.1 Requirements of local applications
[...]
The security of local applications is enhanced if these applications can be effectively isolated from the global Internet.
==> should this "enhancement" be strengthened to a (loose) requirement, or something? Sounds awfully weak to me.. If not, might have a problem with security considerations text.
We see no need to change the current text. Rejected.
On 3/1/03 Pekka Savola wrote:
4.2.1 Privacy requirement of client applications
==> this sub-section should be preceeded by a short paragraph describing why only "privacy" part of "security" was taken into consideration.
==> bigger issue: isn't this text applicable to all cases A-D? Could be placed somewhere else in the document, maybe?
Randomization of the host identifier does however provide benefits. First, if some of the hosts in the unmanaged network are mobile, the randomization destroys any correlation between the addresses used at various locations: the addresses alone could not be used to determine whether a given connection originates from the same laptop moving from work to home, or used on the road.
==> this seems rather an issue for mobile computers, not specific for unmanaged networks.
Second, the randomization removes any information that could be extracted from a hardwired host identifier; for example, it will prevent outsiders to correlate a serial number with a specific brand of expensive electronic equipment, and to use this information for planning marketing campaigns or possibly burglary attempts.
==> if this is the fear, there may be simpler fixes for the problem, e.g. resetting the MAC-address statically to one picked as locally unique. I think there is even a reserved "private use" range, but can't find it at the moment.
On 3/3/3, Ronald van der Pol replied:
It (this text) already is (applicable to all cases A-D). Section 4 is not specific to one scenario, but to all.
Pekka then conceded the point.
No change to current text.
On 3/1/03 Pekka Savola wrote:
Deploying servers usually requires providing the servers with a stable DNS name, and associating the global IPv4 address of the nat/firewall with that name.
==> associating with the address of _NAT/firewall_? If there is NAT, that's something that has to be done, yes.
==> So, if there is no NAT, this needs rewording.
==> s/requires/also requires/ (noticed the intent on second read, perhaps this is enough), else: this overlooks the required step that you must also somehow configure a mapping in the NAT/firewall box.
4.4 Requirements of server applications
[...]
The DNS entries for the server will have to be updated, preferably in real time, if the server's address changes. In practice, updating the DNS is slow, which implies that server applications will have a better chance of being deployed if the IPv6 addresses remain stable for a long period.
[...]
==> please consider the context here. Personally, as one who has services on his home PC (acting also as a router), like SSH access, I don't feel absolute smoothness is a requirement. A nice thing to have, surely, but not a requirement. Unmanaged network is *NOT* the place to run critical services, especially if one has a NAT to traverse -- I'm sure we all agree on that.
Perhaps this should be clarified slightly somehow.
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.
==> "DNS support" should IMO be clarified or elaborated. This is actually not the case, AFAICS. Of course, publishing a DNS update is a problem, but the root cause seems to be configuring the NAT to forward the requests, not the DNS support itself.
We also observe that providing both IPv4 and IPv6 connectivity in an unmanaged network is not particularly difficult; indeed there is a well established experience of using IPv4 in these networks in parallel with other protocols such as for example IPX.
==> this seems a bit like comparing apples and oranges: I'm not aware that external IPX connectivity has been provided by the ISP: anything at all can be used locally, but that's not the point. Perhaps the example scenario needs to be worked out a bit?
On 3/3/3, Ronald van der Pol replied:
I don't think it's about smoothness, but about stability. You want the server to have a stable (over a long time) IPv6 address. And I think services are important for unmanaged networks. Think about all kinds of IPv6 appliances in a home that one can reach from anywhere.
OK, I guess you can read it in different ways. But is says "is difficult to engineer" and I think that is the main point.
On 3/4/03 Pekka Savola continued:
Yes, I very much like to see IPv6 appliances and connectivity in place.
What I was trying to get at with the comment was that the so-called "connection survivability" or "DNS with zero TTL" should not be a problem in the unmanaged networks.
It's nice to have a stable IPv6 address, but one can survive with a downtime of a few hours, even a day (e.g. a delay in updating the DNS, DNS record lifetimes) -- which might not be acceptable in e.g. enterprise networks.
To me "difficult to engineer" doesn't really tell much, because I want to see some answer to the "why is it difficult to engineer?" as the answer is not obvious (or different people have different opinions on why exactly it's difficult).
Add text:
For each service provided by a server, the NAT has to be configured to forward packets sent to that service to the server that offers the service.
On 3/1/03 Pekka Savola wrote:
5.2.2 Addresses and connectivity in Case B
In Case B, the upgraded gateway will behave as an IPv6 router; it will continue providing the IPv4 connectivity of a non-upgraded NAT. Nodes in the local network will obtain:
(same in 5.3.2)
==> the document assumes that in case B, the NAT is being used. That's not necessarily the case.
==> (editorial: "connectivity of a non-upgraded NAT" needs rewording in any case -- I can only try to guess what it means)
On 3/3/3, Ronald van der Pol replied:
True, but in the scenario drafts we try to describe the most common cases. And unfortunatly, it seems NATs are very common.
On 3/4/03 Pekka Savola continued:
In some places, they are; in some others, they might not be. Unless it's very painful, I'd try to cover both cases at least in some detail (so that folks who are *not* harmed by NAT's at that particular place don't throw the scenarios document out of the window as irrelevant).
On Thu 5/1/2003 10:19 AM, Suresh K Satapati added:
I agree with Pekka here in that one who reads it should not think of this as a NAT-only scenario. I propose some minor re-wording for sections 5.2.2. and 5.3.2:
Change 5.2.2 to:
In Case B, the upgraded gateway will behave as an IPv6 router; it will continue providing the IPv4 connectivity. Nodes in the local network will obtain:
- IPv4 natted addresses or IPv4 global address,
- IPv6 link local addresses,
- IPv6 global addresses
Also in the light of site-local debate, please remove the following from 5.2.2.
<snip>
The hosts could also obtain IPv6 site local addresses, if the gateway advertises a site local prefix. This is as debatable: site local addresses provide some isolation to site local application from network connectivity events and network based attacks; however, managing non unique addresses can be problematic if some local hosts are multi-homed, as is common with VPN connections.
</snip>
Similarly, change 5.3.2 to:
The upgraded gateway will behave as an IPv6 router; it will continue providing the IPv4 connectivity. Nodes in the local network will obtain:
- IPv4 natted addresses or IPv4 global address,
- IPv6 link local addresses,
- IPv6 global addresses
Like i stated above, please remove the site-local part from this section:
<snip>
The clients could also obtain IPv6 site local addresses, if the gateway advertises a site local prefix; this raises the same issues already discussed in case B
</snip>
Added text in section 5.2.2:
In some networks, the local hosts will actually obtain global IPv4 addresses. We will not elaborate on this, as the availability of global IPv4 addresses does not bring any additional complexity to the transition mechanisms.
Added similar text in 5.3.2.
Removed references to site-local addresses.
On 3/1/03 Pekka Savola wrote:
5.2.3 Naming services in Case B
At this phase of IPv6 deployment, hosts in the unmanaged domain have access to DNS services through the gateway. As the gateway and the ISP both support IPv4 and IPv6, these services may be accessible by the IPv4 only hosts using IPv4, by the IPv6-only hosts using IPv6, and by the dual stack hosts using either.
==> the first sentence is (almost) always true -- note that IPv6-only host in Case B cannot use DNS services unless they're provided on IPv6 transport. However, you should really elaborate which "DNS services" you refer to. Perhaps in the first line, s/hosts/IPv6-only hosts ... domain also have .../ or the like.
The response to a DNS request should not depend of the protocol with which the request is transported: dual-stack hosts may indifferently use IPv4 or IPv6 to contact the local resolver; the choice of IPv4 or IPv6 will be random; the value of the response should not depend of a random event.
==> s/will/may/ -- depends on several factors?
Soohong Daniel Park [soohong.park@samsung.com]:
==>IPv6-only means it has already provided on IPv6 transport. So we don't need this consideration.
Accept the suggested change, s/will/may/.
On 3/1/03 Pekka Savola wrote:
There are two ways to bring immediate IPv6 connectivity on top of an only infrastructure: automatic tunnels provided by the [6TO4] technology, or configured tunnels. Both technologies have advantages and limitations, which will be studied in a companion document.
==> much as I like e.g. 6to4, this should really be reworded slightly, not to advocate any solution. The simplest acceptable fix would be changing it to:
There are two ways to bring immediate IPv6 connectivity on top of an IPv4 only infrastructure: automatic tunnels, e.g. provided by the [6TO4] technology, or configured tunnels. Both approaches have advantages and limitations, which will be studied in a companion document.
.. or even strike the 6to4 part off completely.
Accept the suggested change, i.e. insert “e.g.” to treat 6to4 as an example.
On 3/1/03 Pekka Savola wrote:
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.
==> (and later, even more so) -- one should perhaps add an informative reference to the ISP scenarios document. In a way, unmanaged team gives a suggestion for the long-term ISP transition plan, and that should be more explicit in the text in some way.
The ISP document is not yet a V6OPS work item. Adding a reference to this document will create undue dependencies in the publication process. In any case, the reference ought to be in the other direction, from the ISP document to the unmanaged document.
Leave text as is. Suggest a reference in the ISP scenario.
On 3/1/03 Pekka Savola wrote:
The loss of IPv4 connectivity has a direct impact on the provision of naming services. An obvious consequence is the gateway will have to be provisioned with the address of a DNS server and with other DNS parameters, and that this provisioning will have to use IPv6 mechanisms.
==> I fail to see why the gateway would *necessarily* have to be configured. Of course, in most cases, it makes a sense to run a caching resolver/forwarder there, but it's not necessary AFAICS. Loss of IPv4 connectivity means that (restricting to the scenario advocated in the document) that the gateway or a host opens an IPv4-in-IPv6 tunnel to the ISP. From there, the DNS services (over v4) could be used directly.
Ronald van der Pol, Wed 4/23/2003 7:52 AM: True :-) It could be another device in the home network. I am not sure we need to reword this. I think this is a minor detail.
Add text to explain that the requirement only applies in the (fairly common) scenario where clients get their DNS configuration through the gateway.
On 3/1/03 Pekka Savola wrote:
6 Security Considerations
Security considerations are discussed as part of the applications requirements. They include:
- the guarantee that local applications are only used locally,
- the protection of the privacy of clients
- the requirement that peer-to-peer connections are only used by authorized peers.
==> I fear this is a bit on the weakish side for security considerations :-(
==> one particular point that wasn't discussed (much) on the draft or here is the connection between applications and possible firewall rules in IPv6 network at the gateway (consider e.g. p2p apps). But this is a difficult problem..
==> in particular, one approach in a document like this could be to try to list some security features currently being used in IPv4 unmanaged networks, and try to identify the issues which will need to be tackled now (later). Solutions aren't necessary in this document, but recognizing the changes in assumptions etc. would be very good. This is *especially* important in unmanaged networks, I'm afraid -- as they seem to constitute about the greatest risk for abuse.
Ronald van der Pol, Wed 4/23/2003 7:52 AM: Pekka admits this is difficult. He gives some suggestions. Maybe this is more appropriate for a separate draft (e.g. like Pekka's IPv6 firewall draft). I don't think we should put too much work in this.
Add text:
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.
On 3/1/03 Pekka Savola wrote:
11 References
[EVAL] Evaluation of Transition Mechanisms for Unmanaged Networks, work in progress.
==> References need to be split ;-) (and given in the proper format), but really: more references should be added, even if informative!
Added references:
RFC 3261 SIP: Session Initiation Protocol
RFC 3022 Traditional IP Network Address Translator
RFC 2993 Architectural Implications of NAT
RFC 2608 Service Location Protocol, Version 2
RFC 3041 Privacy Extensions for Stateless Address Autoconfiguration in IPv6
draft-ietf-dnsop-inaddr-required-04.txt
draft-ietf-dnsop-ipv6-dns-issues-02.txt
On 3/1/03 Pekka Savola wrote:
.. and then for more or less editorial issues ..
==> should you add an informational reference to the latest traditional
NAT RFC?
(I was triggered to this by section 3.4, before it was simple enough..)
==> section titles must be mainly in uppercase (e.g. Local applications --> Local Applications).
==> The text uses active forms like "We saw [...]" etc. Typically, the passive mode is used, but I guess this is also ok.
==> dual stack vs dual-stack (use one for consistancy), similar with IPv4 only vs IPv4-only and IPv6.
==> s/site local/site-local/g, s/link local/link-local/ (everywhere)
Changes have been accepted.
On 3/1/03 Pekka Savola wrote:
Abstract
In order to evaluate the suitability of transition mechanisms, we need to define the scenarios in which these mechanisms have to be used. One specific scope is the "unmanaged networks", which typically correspond to home networks or small office networks.
1 Introduction
In order to evaluate the suitability of transition mechanisms, we need to define the environment or scope in which these mechanisms have to be used. One specific scope is the "unmanaged networks", which typically correspond to home networks or small office networks.
==> Abstract is too terse; it should also include some text on the contents of the memo, not just the background.
New abstract:
In order to evaluate the suitability of transition mechanisms, we need to define the scenarios in which these mechanisms have to be used. One specific scope is the "unmanaged networks", which typically correspond to home networks or small office networks. The scenarios are specific to single link subnet, and are defined in terms of IP connectivity supported by the home gateway and the ISP. For each scenario, transition requirements are inferred from analyzing the needs for smooth application migration from IPv4 to IPv6.
On 3/1/03 Pekka Savola wrote:
==> Abstract/Introduction is out of sync
Abstract was fixed as part of issue 14.
On 3/1/03 Pekka Savola wrote:
==> Introduction should (IMO) give some very brief overview of the layout of the draft ("why sections like this?") -- so that the red line does not disappear when reading it.
Soohong Daniel Park [soohong.park@samsung.com]:
==>I think so, it should be added some text.
Added text:
This document studies the requirement posed by various transition scenarios, and is organized in four main sections. Section 2 defines the topology that we are considering. Section 3 presents the four classes of applications that we consider for unmanaged networks: local applications, client applications, peer-to-peer applications, and server applications. Section 4 studies the requirements of these four classes of applications. Section 5 analyses how these requirement translates in four configurations that can be encountered during the IPv6 deployment: the gateway does not provide IPv6, the ISP and gateway are dual stack, the Gateway is IPv6-capable and dual stack while the ISP is not, and the ISP is IPv6-only.
On 3/9/3, Kurt Erik Lindqvist wrote:
I think this is a good draft. Some editorial comments, I would suggest to have the table of contents in the beginning, and there are references missing in the reference section. Only one minor comment, in 5.1.3 it's said that reverse service is hard to provide. I would say that it is hard to provide for the hosts on the SOHO network, just to be clear.
Accepted the proposed change.
On 3/10/3, Chris Fischer wrote:
Top of Page 10, section 5.2.1: The text refers to the problems with DNS requests when translation is implemented. It might help to include a reference to a draft that discusses these problems, for example, Alain Durand "Issues with NAT-PT DNS ALG in RFC2766"<draft-durand-v6ops-natpt-dns-alg-issues-00.txt>; there are others as well.
Soohong Daniel Park [soohong.park@samsung.com]:
==> I don't think so, this draft don't need to mention of transition issues.
Leave text as is.
None of the existing “NAT ALG issues” draft has yet been accepted as a working group item. Adding a reference now would create an undue dependency in the publication process.
Francis Dupont wrote:
Ronald van der Pol: True. But do we need to do something with this remark? There already is draft-ietf-dnsop-ipv6-dns-issues-02.txt.
Added reference to draft-ietf-dnsop-ipv6-dns-issues-02.txt.
Alain Durand wrote:
Ronald van der Pol: I don't think we need this split. In the scenario draft we say the hosts need some kind of IPv6 connectivity. Either by a cooperating ISP or somewhere else. In the analysis draft we explore this further.
Leave text as is. The two options will be discussed in the evaluation document.
Erik Nordmark wrote:
Section 4 says at the end of the first paragraph "simple and easy". I think we should replace this with "secure and robust" or add all the motherhood and apple pie.
My point is that by only including two motherhood words and not others an attempt to use this document to evaluate potential solutions might be slanted towards "easy" instead of "good".
I suspect the WG needs to discuss this aspect of the spec.
Rewrote offending text as: “the deployment of these IPv6 applications should be simple and easy to manage, but the solutions should also be robust and secure.”
Erik Nordmark wrote:
Section 3 makes a, in my opinion artificial, distinction between "p2p" and "server" and then goes on to conclude that server is out of scope due to the difficulty with DNS updates. This distinction seems a bit artificial since the p2p aspect (that the same nodes both initiate and respond to traffic) doesn't preclude that DNS is used. So I'd think the document should capture that DNS updates might have issues when the network is unmanaged that is independent of the types of applications in section 3.
Added text in section 4.3: (Peer-to-peer applications that rely on the DNS for name resolution have the same naming requirements as server applications, which are discussed in the next section.)
Erik Nordmark wrote:
Minor things:
Per the rfc-editor the abstract and introduction should not be identical.
Section 2:
I'm assuming (but the document isn't clear) that if somebody figures out how to autoconfigure a set of routers ("zerouter") that a network with multiple links would be in scope. Or is the intent that such networks always be out of scope? It would be good to make this clear.
Section 3.2:
Is outbound SIP calls an example of a client application? The reason I think it makes sense to make this explicit is because the current examples are those that trivially work across a NAT box and if this is the definition of "client application" it would make
sense to make it clear, and if the definiting is something different (an entity that initiates communication) it would make sense to make that clear.
Section 4.1 says:
The security of local applications is enhanced if these applications can be effectively isolated from the global Internet. Seems orthogonal to this document and a distraction.
Section 5.1.2 says "have to involve tunneling over UDP"
but in general using PPP over TCP works over NAT as well. If you are trying to capture some specific requirement that excludes PPP/TCP that needs to be explicit (and I suspect some folks will disagree with such a requirement).
Section 5.2.3 talks about
There must be a way to resolve the name of local hosts to their IPv4 or IPv6 addresses. Why isn't this a requirement in section 5.1.3 as well?
Section 6 says:
- the guarantee that local applications are only used locally,
I fail to see what this has to do with the coexistence between IPv4 and IPv6. *If* there is such a requirement wouldn't that requirement exist today in IPv4 and wouldn't it exist in IPv6 even after IPv4 goes away? If this is the case I don't think the requirement belongs in this document but in a document for "requirements on home networks" or something like that.
Abstract and introductions have already been rewritten, see issues 14, 15, 16.
Text on multi-link subnet has been added as part of resolution of issue 2.
The SIP client is already listed as an example of peer-to-peer application.
There have been contradictory comment on the need to mention security of local applications. (See issue 3.) Suggest to leave the text as is.
Update section 5.1.2 says to mention “tunneling over a protocol that can traverse most NAT, i.e. either TCP or preferably UDP."
There is no requirement in section 5.1 to perform local applications over IPv6 – 5.1. is about isolated hosts. There is thus no need to discuss local name resolution.