Fred Templin wrote:
Brian,
Thanks for sending the detailed comments. Will give a first-pass at them below, but may require a couple of iterations.
Fred [EMAIL PROTECTED]
Brian Haberman wrote:
[WG chair hat off]
Below are my comments on the Hain/Templin draft. Globally, I think that these goals are worthwhile for the entire IPv6 protocol suite. This type of functionality is needed in order for people to feel comfortable migrating from v4 to v6.
Goals for an Addressing Scheme to Support Local Communications within Sites
The title still implies that these goals will be satisfied by an addressing scheme rather than some other mechanism. As it has been noted in the past, some of these goals are not specific or require a local addressing scheme. In fact, some of the "goals" are really operational rather than addressing issues.
Actually, Ralph Droms had a similar comment (see his post on this thread) and suggested the following title:
"Goals for Local Communications Within Sites"
That sounds better to me. It focuses the discussion on the aspects of local communication without hinting at a solution.
If we can separate out the operational issues from the local addressing goals, the title may fit better.
I like Ralph's title suggestion; any others?
1. Introduction
The IPv6 addressing architecture [RFC3513] specifies global and local-use unicast addresses. Global addresses are understood to have unlimited range and may be used as the source and destination addresses in packets that originate from any point on the connected global IPv6 Internet. Local-use addresses are intended for use only within the range of a single link/site, but their specification does not address operational considerations and does not account for the esoteric nature of terms such as "site".
I cannot determine what the last sentence is trying to say.
How about:
"...but their specification does not address operational considerations for real-world deployments."
So with the title change, I would suggest re-writing the Intro to focus on the aspects of local communications. Describe the characteristics/features of local communication that need to be preserved. You could keep some text on local addresses as an example.
Further along in the document, it expressly talks about operation considerations. In fact, the whole document assumes that these considerations should all be fixed by a local addressing scheme.
Not the intention, and will work to fix this. We want to support local communications within sites, but this need not be through a *local addressing* scheme.
Perhaps what needs to be discussed here is why only having global addresses would not suffice. Describe the operational problems that will be caused without local addressing.
Any specific text suggestions would be welcome.
There is a perceived need for an addressing scheme that supports local communications within sites. Of special interest are "active sites", e.g., sites that are intermittently-connected or disconnected from the global Internet, sites that frequently change provider points of attachment, sites that temporarily or permanently merge with other sites, multi-homed sites, etc. This memo will discuss goals for an addressing scheme to support local communications within sites in the context of real world deployment scenarios.
I find the use of the word "perceived" in the first sentence of this paragraph and in other places in this document. If it is just a perceived need, can't these goals be solved with other tools? Or put in other terms, will operators use different tools if they are provided/defined/developed?
Well, there is an actual need for local communications within sites and any form of communications requires addressing. Would your concerns be satisfied if we struck the word "perceived" wherever it occurs?
Yes.
Also, multi-homing is a different issue altogether. I can't see where it needs to be discussed other than as a subset of a possible renumbering scenario.
Like my comments on the introduction, I would firm up the issues caused without local addressing.
Again, specific text suggestions would be welcome.
I would suggest just dropping the reference to multi-homing in this case.
I also suggest that multi-homing be taken out of this document.
Agree; we already have RFC 3582 and don't want to re-create it here.
3.1 Easy to Acquire
Some portion of the address space should be made available that requires no public registration, payment, customer/provider relationship, or approval. These addresses should be architecturally supported and end-user-controlled.
A few issues with this section.
First, why is no payment a goal as far as ease of acquisition is concerned?
Not intending the non-payment aspect for the entire address space, as indicated by: "*Some portion* of the address space..". What we are intending to say is that some scenarios may require autonomous address configuration with no interactions with a registry, and those scenarios should be supported.
OK. Then I would recommend stating it in that fashion. That is, some portion of the address space should be obtainable with no payment and no registry interaction. An example would be useful as well.
Second, how can conflict resolution occur without some form of public registration? No registry is fine if we are talking about a strictly disconnected network, but for connected networks a conflict resolution capability is a good thing to have.
Not what we're intending to say; clearly, some scenarios will require conflict resolution such as can only be enforced through public registration. We touch on this in section 3.5.
How about some discussion on whether conflict resolution capability is more/less important than no registry/payment?
Third, I would suggest some text be added to discuss the tradeoffs of the global routability of these addresses.
Suggestions?
3.2 Stable
Applications that enable local communications should use addresses that support session stability (i.e., connection survivability) during intermittent connectivity, site mergers, change to a new provider, etc. In particular, session stability should not be affected by renumbering events [BAKER].
How often do you expect renumbering events to occur?
In fixed environments, perhaps quite rarely; in mobile environments, perhaps quite often. This seems like a question for [BAKER].
My point is more in terms of how this document wants to define stable. In my view, stability has different meanings when discussing the renumbering of a network versus having that network be subject to intermittent connectivity to the Internet. In the former, you expect a drastic change to occur to the prefix(es) in use. While in the latter, it is quite possible that the same prefix will remain in use as long as your point-of-attachments are to the same provider.
How does renumbering differ from a planned outage? When those occur, applications either restart or are restarted once the change is made.
We don't want applications to have to restart; we want them to continue through to completion.
In addition, just because a subnetwork disconnects, it doesn't terminate the use of prefixes within the subnetwork. So, the apps can keep using those addresses until the nodes are told of new ones.
The requirement seems to be for a stable address for a long period
of time (months, years, decades, etc). If that is the requirement,
then state it as such.
Long period of time, perhaps, but how long is difficult to quantify. Again, perhaps this is a question for the [BAKER] renumbering draft.
I think it is quite pertinent to this draft. How long must an address remain stable in order to satisfy this document's stability goal?
3.3 Multiple Link Support
Addresses for local communications within sites should support operation over multiple links, e.g., via L3 routing, L2 bridging or some combination thereof. As such, subnetting consistent with the recommendations in ([RFC3177], section 3) should be supported.
Link-local addresses in IPv6: "are designed to be used for addressing on a single link for purposes such as automatic address configuration, neighbor discovery, or when no routers are present" ([RFC3513], section 2.5.6). By definition, link-local addresses have a single link range of operation and will not meet this goal.
I don't think this section even belongs here. We have link-locals defined already, so someone will not re-define them. I suggest taking it out altogether.
Remove all of section 3.3, or just the second paragraph? (The first paragraph is the only text in the document that speaks to the possibility of subnetting within the site.)
Taking out just the second paragraph should be fine.
3.4 Well-known Prefix
I think this section is an excellent example of trying to solve an operational issue with an addressing scheme. Several people have suggested this before, but a "well-known" prefix can just as easily be carved out of one's global prefix.
In addition, how exactly does an app figure out "the hint"? It has no way of knowing which side of the site boundary it currently resides. The well-known prefix works for filtering at boundaries, not for special handling by an app.
I have no opinion on this question; do you have anything to add on this subject, Tony?
3.5 Globally Unique
Addresses used by sites should be globally unique such that site mergers will not result in collisions. Global uniqueness is based on the statistical properties of address allocations, therefore proposals should specify a suitable means for random prefix generation. Addressing scheme proposals should also provide a suitable means for conflict resolution, e.g., certification through a central registry, distributed database, etc.
Doesn't this directly conflict with the requirement in 3.1 for no public registry?
As I mentioned in response to the section 3.1 comments, we want to support both those scenarions that require autonomous address configuration with no registration in which statistical uniqueness is sufficient, and those that require conflict resolution and true global uniqueness as provided through a registration authority. Can you suggest a way for us to clarify?
Perhaps the initial list of requirements should spell out the relative importance between requirements. Is it more important to have a registry that assists with conflict resolution or having no central registry? Or are they equal and a solution should try and provide both?
Sufficient global uniqueness is needed to support, e.g.:
o VPNs between enterprises
o dynamically created VPNs in support of temporary virtual organizations
o service provider co-location of hosts that reside in the address space of multiple customers
o formation of virtual organizations (Grids) among enterprises
o mergers and acquisitions of enterprises such that address spaces do not collide
I am confused by this list. One could argue that all of the above put together requires globally routed addresses.
The objective of this document is to present the goals for local communications within sites; not to argue for one solution alternative over another. If others use this document as a talking point for arguing the solution alternatives, then the document will have served its purpose.
Perhaps the better way to approach this is to discuss the tradeoffs of centrally-allocated addresses and locally-allocated addresses in supporting tools such as VPNs.
OK, if f we can do so without departing from the goals focus and getting too close to the realm of solutions. Any suggetions would be welcome.
3.6 Usable in the Absence of a Provider
Active sites need addresses that can be used when there is no active link to a provider. In the case of intermittently-connected sites, provider access may be unavailable for long periods but this should not disrupt local communications within the site. In the case of sites moving to new provider points of attachment, frequent renumbering events may occur but, again, local communications should not be disrupted.
The current scheme for renumbering allows for overlapping of the old and new prefixes for a period of time. This would apply to the intermittently-connected sites as well. Apps can continue to use the old prefixes for internal sessions until the pre-planned, hard cutover. Once that cutover occurs, the apps will disconnect from the old prefix and re-establish through the new prefix.
OK.
PI addresses provide one solution alternative genre that also appliies to cases where network managers want global access. The issue is that PI addresses with no designed aggregation properties may lead to global routing table explosion (if advertised outside the site) given current routing technologies. For this reason, PI addressing scheme proposals should either provide reasonable aggregation properties or a detailed analysis of their interactions with global routing technologies. PA and other non-PI proposals should explain how the proposed addressing schemes will support local communications in the presence of intermittent and/or disconnected provider access.
What is the purpose of having this short discussion of PI addresses
in this document?
Well, your point could be made that this is getting away from goals and touching too closely on solution space. I could live with dropping this text, if that is what you are suggesting. Tony?
I don't see the benefit of having a short discussion of PI space in this doc, so I would suggest removing it.
3.8 Compatible with Site Naming System
Since the document assumes that addressing will be the solution, why have this section on naming?
Didn't quite understand this comment; can you clarify?
Is this section specifying a requirement that any solution be compatible with DNS? Should an addressing-based solution refrain from adding new DNS records? Should it refrain from using two-faced DNS?
3.9 Compatible with VPN
See my comments on section 3.5. This is a prime example for the use of global addresses.
If you think this is getting away from goals and coming too close to solutions, please explain; the section seems to be describing a goal to me.
4.1 Border Filtering
Network managers limit specific applications to internal use, so they configure them to only work with a filtered address range. This simplifies the border filter to an address prefix, rather than needing to employ deep packet inspection to track a potentially dynamic range of ports.
Again, if they are connected to the Internet, they can carve out a portion of the global prefix IF you want to rely on this type of filtering for "application protection". I have the same concern about this section as raised with section 3.4 In discussing the issue of filtering, I would like to see the tradeoffs, e.g. real cost, of using a portion of your global space vs. local addresses.
Again, I'll have to ask that Tony comment on this one.
4.2 Maintaining Confidentiality of the Address Space
Private space may be used to avoid exposing to competitors what internal networks they are deploying and which office is coordinating that effort. Network managers also don't have to expose business plans to a registrar for evaluation for networks that are not attached to the global Internet. Some have stated that if they are required to register for public space for every internal use network, they are more likely to pick random numbers than tip off the competition.
Can you give an example of how this works? Knowing what someone's prefix is doesn't reveal what internal networks are being deployed.
This one also for Tony.
4.3 Test Networks
Another significant use of private address space is test networks. Frequently these are large, elaborate networks with a mix of public and private address space. Use of random unallocated space runs the risk of collision with legitimate addresses on remote networks.
But you can mitigate that risk if you sub-divide your public space and filter the chunk you want private.
4.5 Mobile Router with Personal Area Network
4.6.2 Groups of Nodes that Travel Together
I made this comment earlier, but it applies to these two sections as well. Just because a network is dis-connected, does not mean it can't keep using the prefix it was assigned when it was connected.
Well, again we are talking about goals here - not solutions. The goal is to support local communications within groups of nodes that travel together with possible long periods of intermittent/disconnected access. The solution is out of scope for this document.
My concern is more with the distinction between a renumbering event and re-connection to the same provider. The latter can allow you to continue using the prefix you were originally given.
I suggest that this section spell out the issues of long-term use of an ISP-assigned prefix after the dis-connection. And that this take into account whether the customer has negotiated the rights to "keep" the prefix during the intermittently connected time.
But, would this take us back into solution space again?
Research ships at sea intermittently connect via INMARSAT, or when in port, the shipboard network is connected to shore via Ethernet. Of utmost importance is that the systems on board the ship all function, providing data collection and analysis without interruption. Static addressing is used on most intra-ship network components and servers. It's quite expensive to operate a research ship, so eliminating points of failure is important. Scientists on board collaborate with colleagues back home by sharing of data and email. Currently private address space is employed for several reasons: 1) it provides the ability to allocate significant address space to each ship without needing to worry about how many computers will be on a given cruise. 2) it provides separate address space for each ship. 3) it simplifies filtering to ensure shipboard traffic is not permitted to transmit out or bring up expensive satellite links.
Point 1 is a no-op, it can be accomplished with almost any addressing mechanism. Point 2 screams for the use of global addresses. And 3 can, once again, be accomplished through many other means besides a special address range.
Are you suggesting any changes for the document in this comment?
Well, the last portion talks about some important issues. The current use of IPv4 private addresses is done to accomplish those three points. Those are important to know. So I think they need to be closer to the beginning of the document as target goals.
5. Perceived Advantages of Limited Range Addressing Solutions
Limited range addressing solutions allow filtering, and filtering creates addressing boundaries no matter where the bits come from. The point is that some addresses are only valid within the range defined by the local network manager.
I agree with this sentence. Some addresses are only valid in an area defined by the manager. And that can be accomplished in several ways.
OK.
In the simple case, hosts that are allowed external access have a policy that allows them to configure both global and limited range prefixes, while those that are not allowed global access have a policy that only allows limited range. Address selection policy tables might need modifications to enable the selection of limited range address space over global addresses. Given such modifications, address selection rules will prefer the smallest range so internal communications are forced to stay internal by the hard filter at the border.
If an application chooses to assert a policy that is different from the network manager's filtering rules, it will fail. Having a well defined limited range address space that is known to have filtering applied allows applications to have a hint about potential range restrictions. We can choose to leave the network managers to figure out their own adhoc mechanisms, or we can put them in a structured limited range address space so that applications will have a chance to react appropriately.
This paragraph raises the point that the proposals by Zill and Bellovin or other similar approaches to advertise "special" prefixes via an RA may be useful tools for us to provide. And I am sure others will see the same. Perhaps there needs to be some wrap-up on the operational issues between using such an approach and using a local addressing scheme.
OK; we can investigate this further.
Regards, Brian
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
