[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
MAST Review JimBo
Dave,
Attached are revs of MAST and CHOICE. Bottom line is I think MAST
should just stick to multiaddreses injection btw transport and IP layer.
But, I think SCTP does this fine and any extensions your model proposes
is input to SCTP.
I think also you should label MAST as a "Reference Model" stage no one
could implement this except maybe a rapid base prototype and then only
by consulting with you. Not ideal for implementation. So for now I
believe you have a model. But I see no advantage at all over SCTP and
SCTP does this naturally to support multiple addreses and has mechanisms
to add them and delete them. The model discussion is fine here and part
of the multi6 charter for problem to solve at hand. But the actual work
on a real architecture and spec I think would be done as new WG in
Transport Area. But as I said SCTP solves this problem.
On CHOICE I think this should become two drafts and orthogonal to MAST.
One is a draft on emerging terminology that would exists next to our
multi6 requirements. The other one would be the long list of
"assumptions" you state about our required terminology. These should be
separate efforts and have nothing to do with MAST.
Regards,
/jim
ABSTRACT
Classic Internet transport protocols use a single source IP
address and a single destination IP address, as part of the
identification for an individual data flow. TCP includes these
in its definition of a connection and its calculation of the
header checksum. Hence the transport service is tied to a
particular IP address pair. This is problematic for multihomed
hosts and for mobile hosts. They cannot use more than one, for
any single transport association (context). Multiple Address
Service for Transport (MAST) defines a mechanism that supports
association of multiple IP addresses with any transport
association. It requires no change to the Internet
infrastructure, no change to IP modules or transport modules in
the end-systems, and no new administrative effort. Instead, it
defines a layer between classic IP and transport that operates
only in the end systems and affects only participating hosts.
Additional functionality is obtained by use of a DNS and
"presence" rendezvous service.
JB> Adding a layer between the transport and IP layer that supports the
Internet Protocol suite is not trivial, significant to implementations, and
must maintain cohesion between the two layers regarding state of a
connection.
CONTENTS
1. INTRODUCTION
1.1. TERMINOLOGY
1.2. DISCUSSION VENUE
1.3. DOCUMENT HISTORY
2. REQUIREMENTS
3. PROTOCOL
3.1. TRANSACTION MODEL
3.2. ASSOCIATION ATTRIBUTES
3.3. THE INIT OPERATION
3.4. THE SET OPERATION
3.5. THE PROBE OPERATION
3.6. THE SHUT OPERATION
3.7. THE ERR OPERATION
4. TRANSFER SERVICE
5. SOURCE VALIDATION
6. RENDEZVOUS
6.1. DNS
6.2. PRESENCE
7. PATH SELECTION
8. IMPLEMENTATION
8.1. TYPICAL TRANSPORT INTERFACING
8.2. MAST THROUGH NAT
8.3. MAST AGENT
9. SECURITY CONSIDERATIONS
APPENDIX
A. ACKNOWLEDGEMENTS
B. REFERENCES
C. AUTHOR'S ADRESS
D. FULL COPYRIGHT STATEMENT
JB> TOC should have page numbers.
INTRODUCTION
Classic Internet transport protocols use a single source IP
address and a single destination IP address, as part of the
identification for an individual transport data flow. For
example, TCP includes these in its definition of a connection and
its calculation of the header checksum. Hence a classic
transport association is tied to a particular IP address pair.
This is problematic for multihomed hosts and for mobile hosts.
Both have access to multiple IP addresses, but they are prevented
from using more than one within an existing transport exchange.
For a host to use a different IP address pair, participants must
initiate a new exchange. In the case of TCP, this means a new
connection.
In recent years, there have been efforts to overcome many of
these limitations, through different approaches at different
places in the Internet architecture. Some modify the IP
infrastructure, with embedded redirection services. Some define
transport enhancements to support a set of addresses directly,
and some define a layer between classic IP and classic transport.
Each of the existing proposals has notable limitations in
functionality, implementation, deployment or use. A discussion of
the architectural choices and summary of existing multiaddressing
projects is in [CHOICE].
JB> Comments are provided to [CHOICE} in other review.
Multiple Address Service for Transport (MAST) supports
association of multiple IP addresses during the life of any
transport instantiation, by defining a layer between IP and
transport. It operates only in the end systems and affects only
participating hosts. MAST does not require modification to the
Internet infrastructure and does not require modification to any
host's IP or transport modules, although improved functionality
can be obtained with some changes.
JB> Adding a layer between the transport and IP layer that supports the
Internet Protocol suite is not trivial, significant to implementations, and
must maintain cohesion between the two layers regarding state of a
connection.
Further, MAST works with existing IPv4 and IPv6 transport
services and it is useful to any two hosts that try to use it
JB> The transport service other than checksum is no different between
IPv4 and IPv6. This statement is miss leading the reader.
with each other. It does not define any new naming or addressing
structure. It has no additional packet header overhead and
minimal additional packet-processing overhead. It employs
existing administrative structures. Hence MAST has a low barrier
to adoption and use, while permitting more advanced functions
with more extensive adoption and modification.
JB> Any changes to the IP stack on any implementation requires
extensive review and analysis and must be checked for performance
costs and affect to the robustness of that new code. The above
should state that for the causual reader. Above implies other
wise.
MAST may be invoked at any time, before or during a transport
association. A host may initiate and conduct a classic, single IP-
pair TCP connection. It may then separately query for remote host
support of MAST and initiate a MAST exchange to be used by that
connectivity. Either participant is then free to add or remove
addresses. Of course, use of MAST may instead be performed before
a transport context is established, so that future contexts
immediately have access to multiple IP addresses.
JB> SCTP does this very well and is well defined transport
protocol widely implemented and available today in products.
I understand it is discussed in CHOICE but it should be
mentioned here so a reader knows there is a significant
alternative and worked on in the IETF community.
For a multihomed host, it will be reasonable to associate
multiple IP addresses with a transport context at the time the
JB> Replace context with association above and throughout the doc.
first context between that host-pair is initiated. For a mobile
host, addresses may be added and removed as the host moves across
the Internet fabric, acquiring and losing use of different IP
addresses.
JB> Replace acquiring/losing with adding/removing. Remove "fabric"
it is redundant word next to Internet in this context.
Over the life of a mobile transport context,
different addresses might be active at different times. Support
is provided for continuation of service across complete
connectivity interruptions to mobile hosts, when a host's set of
available IP addresses becomes empty and the host later re-
acquires a usable IP address.
JB> The above mobile wording is very poor have you read MIPv6
the IETF has clear terms and methods to refer to this please
be consistent with our work in other groups.
NOTE: The MAST proposal exploits the considerable
HIP work done to uncover usability issues and
edge conditions. MAST suggests the same core
functionality as HIP and LIN6, and a similar
approach, but uses a simpler protocol, with a
somewhat narrower functional focus.
JB> I find this to be handwaving and political to push this
spec in the same way technically as HIP and LIN6 and this
is not the case. This spec is not even close to the type
of technical narative as HIP and LIN6, at this time.
ALso references in this spec where this is proven or
CHOICE should be supported or this NOTE should be
removed.
1.1. Terminology
This proposal considers a method that will enable an endpoint
(host) to use multiple addresses during single application
associations (sessions).
"Agent" refers to a forwarding service that represents an
endpoint for multiaddressing.
JB> This is all that is needed for Terminology the below is
not relative.
For mobility, the agent resides on
the "home" network and relays datagrams to the endpoints actual
location on the Internet. The endpoints are modified to support
this forwarding technique. For multihoming, an agent hides the
presence of multiple addresses from the endpoint located on the
local network.
"Mobility" refers to the availability of different addresses over
time.
JB> Same comment as above. This is completely different than everyone
elses definition of mobility in the IETF I know but ok its your spec.
This may even include discontinuities, with no available
addresses, at times. It also may include overlapping availability
of addresses. Interestingly, this looks the same as multihoming.
"Multihoming" refers to the availability of multiple addresses
simultaneously.
JB> This is completely wrong and see Multi6 Requiremens document for one
definition of multihoming. Same comment as above.
It is typically used to refer to multiple network
attachments for a host, but works equally well for multiple
upstream network attachments by the local network, when the
different upstream addresses are visible to the host.
Interestingly, multihomed environments often must support dynamic
changes, such as when adding a new upstream provider. Therefore,
multihoming can include mobility features and mobility can
include multihoming features.
"Path discovery" provides a sender with the means for learning
about the addresses from which they can send.
JB> This is address discovery not path discovery. Bloating
and overloading terms to be perceived to be something other than
what it is does not help this specs clarity.
"Path selection" is required when more than one address is
available to the sender. Although the sender is limited to
specifying an address, rather than a path, it appears that
thinking of it as path selection aid consideration of solutions.
In effect, it formulates the selection task as being similar to
the job of routers.
JB> Sentence is far to long and needs to be broken up at a
minimum. But implementors have to code to what is in the
spec not what it can make one think of in a spec? Address
selection is better. I suspect your trying to be all things
to all people who read this for identifiers and locators. Bad
to support politics in specs.
Route formulation is mature technology, so
that this aspect of multiaddress processing will be tractable, if
not straightforward.
JB> So? Whats your point?
"Rendezvous" permits a host that is initiating an association to
find the target of the association, such as a client finding a
server. "Finding" means obtaining a valid address for the target.
A public process is required for rendezvous. The primary Internet
mechanism for rendezvous has been the Domain Name Service (DNS).
The DNS used long, variable-length strings (names) and is
tailored for large-scale rendezvous with names and addresses
(mappings) that change infrequently.
1.2. Discussion Venue
Discussion and commentary are encouraged about the topics
presented in this document. The preferred forum is the
<mailto:multi6@ops.ietf.org> mailing list, for which archives and
subscription information are available at
<http://ietf.org/html.charters/multi6-charter.html>.
1.3. Document History
-00 Initial proposal. Basic concepts. Heavy reliance
on SCTP and DCCP for style of solutions and
implied detail.
-01 Substantial reorganization.
Added more detail to MAST, including rendezvous
and agent, adjunct services
Extended discussions about alternative proposals
and architectural issues, moved to -analysis-
draft.
Removed explicit SCTP/DCCP usage.
Removed NAT references from architecture
discussions.
2. REQUIREMENTS
MAST has four requirements:
a) The goal for this service is to support the use of multiple IP
addresses by either participant in a transport association.
JB> Change participant to peer.
b) The service should require no changes to the IP network
infrastructure, to the IP layer in end-systems, or to the
transport layer in the end-systems.
All knowledge of the service, and all activity about it,
must reside only in the end-systems using it. In order to
avoid start-of-association operation, the service must
support operation of classic transport associations, with
post-hoc introduction of the multiaddress mechanism.
c) The service must be resilient against classic, basic security
threats, especially spoofing (association hijacking).
d) The service must operate across administrative and operational
boundaries and across address translation boundaries (NAT).
3. PROTOCOL
This section discusses MAST operations between participating
hosts.
3.1. Transaction model
MAST uses a simple request/response. Each request receives a
response. The response forms the basis of MAST transaction
reliability. A request is retransmitted when a response is not
received. Retransmission rules use the usual exponential
backoff.
JB> How are the request/response transmitted?
<STATE As guidance about the association
DIAGRAM> relationship between two participating MAST
hosts, SCTP Section 4, "SCTP Association
State Diagram" provides a useful, starting
framework. See [SCTPMOB] for discussion of
mobility enhancements that are applicable
to MAST.
JB> I really have an issue with this. Put a MAST diagram in here
this is the first reference to SCTP in the spec now. MAST spec
should build and show its own state diagram.
JB> Also this section 3,1 needs to discuss the transaction model and is
completely missing here. It is not discussed further down in the spec
either. This is a huge hole.
3.2. Association Attributes
An MAST association is between a pair of hosts, defined by
endpoint identifiers, an association label and a transaction
sequence identifier.
It comprises a domain name double, an Association Nonce double,
and a transaction sequence number (TSN) double:
Endpoint Globally unique, macro-labels
identifiers: comprising a domain name for each host
Endpoint Association nonce, with cryptographic
association protection against hijacking. It is an
label: internal identifier for the MAST
association; it comprises a random
value, such as defined in Section
6.4.2, "Connection Nonce Feature" and
used in Section 6.4.3, "Identification
Option", in [DCCP]. Also see [RAND].
Sequence A Transaction Sequence Number (TSN)
label: indicates data flow during the
association and is used for detecting
duplicates, detecting missing data,
and correlating responses
NOTE: More complex association behaviors are
possible, such as permitting specification of
address subsets for different transport
context. This level of sophistication is beyond
the scope of the current effort, but will be
interesting to explore after a basic capability
is achieved.
JB> The above is not descriptive enough even for a model
piece of work let alone and architecture or implementation
spec.
3.3. The INIT Operation
JB> The transaction model needs more definition before this
section.
At the beginning of a MAST session, each host sends an "init"
element, to create a host-pair association and define the initial
set of valid addresses that may be used. The association is fully
established after each host has received an acknowledgement to
the "init" operation that it sent.
JB> What does beginning to above refer too? I am lost? Is the init
in a TCP packet? A UDP packet etc?
The "init" operation includes:
* Sender and Receiver domain names
* Association Nonce
* TSN
* List of sender IPv4 and IPv6 addresses
JB> So the host above has to go out of band (note in most implementations
that is in the kernel where network subsystems exist) and find the domain
names? Of the src/dst address? Its not clear above.
JB> You present a model not a spec or archictecture is what I think now.
SCTP is fully specified protocol you should not compare this to SCTP
in any way other than a model and the model needs more work here.
3.4. The SET Operation
When a host wants to specify a new list of its own IP addresses,
supported in this MAST association with the other host, it sends
a "SET" operation to the other host.
This function is isomorphic with the INIT operation, except that
it uses the existing "Association Nonce" and continues the
existing TSN sequence.
JB> How can it be isomorphic and maintain same TSN space?
The domain names must be the same as were
used in the "init" operation for this association.
A SET operation may occur after a complete interruption of
service, such as when a mobile host has not had connectivity for
a time, and then reacquires access to the network. In this case,
the set of sender addresses is likely to have no members in
common with the set that was valid before the interruption.
NOTE: A complete list of valid addresses is included,
rather than specifying only incremental
changes. The list of valid addresses is small
and does not require the synchronization
complexity of an incremental function.
JB> This should be more than a note but integral to the discussion.
3.5. The PROBE Operation
Status of the association is queried with the "probe" operation.
It serves three functions:
JB> Which nodes are you speaking of needs to be included for context.
* Permit a sender to discover the IP address and port number,
being presented to a receiver, if subject to NAT
transformations; the receiving MAST participant responds with
the sender's IP address and port number it received in the IP
datagram for the PROBE operation.
* Confirm the continued utility of the destination address used
for the PROBE operation.
JB> What does confirm the continued utility mean?
* Provide an association keep-a-live.
JB> How is this done exactly? I know what TCP keep-a-live is?
The "probe" operation includes:
* Association Nonce
* TSN
* Sender and Receiver IP addresses
The IP addresses in the "probe" operation are the same as are
specified by the sender in the containing IP datagram.
The "probe response" operation includes:
* Association Nonce
* TSN
* Received MAST Probe-level Sender and Receiver IP
addresses
* Received IP-level Sender and Receiver IP addresses
3.6. The SHUT Operation
The SHUT operation terminates use of MAST between a host-pair; it
uses a 3-way graceful close, with no half-open state.
The "shut" operation includes:
* Association Nonce
* TSN
* Sender and Receiver domain names
3.7. The ERR Operation
ERR elements are sent, in MAST, when there is an error.
The "err" operation includes:
* Association Nonce
* TSN
* Error information
JB> All of the above section needs more description and technical depth
with explanation and needs to be expanded. It is quite unclear.
4. TRANSFER SERVICE
The MAST control exchange has modest transfer (transport)
requirements, except that it must itself be able to operate by
using multiple IP addresses for each host. Transactions are
small and are expected to be infrequent. However they must be
reliably delivered, and they must be secure, with respect to
redirection and replay attacks by third parties.
A simple use of UDP will suffice, with MAST responses providing
the needed transfer acknowledgement. The full specification will
provide for retransmission controls.
JB> Ok then call this a model.
Security is built into the MAST protocol, rather than its
transfer service.
JB> Thus far I see no protocol defined for MAST so I don't know
how to gauge what that means and verify this is true from reading
this spec.
5. SOURCE VALIDATION
The minimal level of implicit source validation that exists
within existing transport services' use of IP is eliminated with
multiaddressing. This invites hijacking attacks.
JB> Uh.........help me how do you not use IP again??????????????
Not clear what your trying to define or say.
At the start of an association, MAST establishes association
nonce that is used for later exchanges. This nonce is created
while only one address is in force.
The method of establishing the nonce will follow the lines of
PBK, SCTP or DCCP, as dictated by the limited security
requirements to prevent hijacking.
6. RENDEZVOUS
How does one endpoint find another? The current answer is DNS.
However multiaddressing introduces some challenges. Classic DNS
use permits finding a set of addresses associated with a domain
name. For finding a static, multihomed target, this is probably
sufficient. The fact that the initiator is mobile can be
communicated to the target by the initiator.
JB> This means nodes are doing DNS lookups twice or in a the model
MAST forces additional name service lookup once potentially in
user space to get the address now in the kernel to get another
address. During a TCP transaction that could be a problem
especially when a node is moving at 1000 mph.
However when the target is mobile, an additional support
mechanism is needed. This section defines an adjunct service to
finding mobile targets.
JB> OK so now you hand wave. Just take mobility out of this spec is
my advice.
6.1. DNS
Rendezvous with mobile targets is supported through a two-stage
process. A domain name is used as the stable, public EID.
JB> We have not even agreed to what an EID is in mutli6 I doubt your
going to get away with this here.
An SRV record is defined to reference a dynamic "presence"
service through which an endpoint can register its current set of
IP addresses.
JB> Errrrrrrrrrr. This is far to much overhead to do in an IP stack
betweent the transport and IP layer. SCTP was invented and built to
solve this problem. Dave tbis is a hack job to the stack.
6.2. Presence
The requirement to discover current IP addresses for an endpoint,
and to be notified when they change, suits existing presence
service models rather nicely.
MAST is defined to use the presence service available through
[XMPP]. The definition of this mechanism will be for standard
XMPP, with some addressing conventions to specify the target
system's domain name at a particular presence server.
Development of the detailed specification may lead to choosing a
different service. However, dynamic rendezvous is an adjunct
function for MAST. Hence it is not essential to develop this
capability for initial use of the service.
JB> Have to see the use case and spec addition. No comment.
7. PATH SELECTION
Having gained access to the list of IP addresses by which a
destination host may be reached, a sender must select one, for
the next set of data. As with any dynamic resource selection
opportunity, the choice of schemes is extensive and can be quite
sophisticated. However until there is experience with the basic
dynamics of this service, conservative usage models are
encouraged.
As with SCTP, the conservative approach is to choose a primary
address and use others as alternatives only to ensure robustness
to the association. Periodic use of the PROBE operation to each
addresses that the other side purports to have available will
provide basic path availability and performance data.
JB> No comment how you can even compare this to SCTP is beyond me.
SCTP is a finely tuned transport protocol this is at best an idea.
8. IMPLEMENTATION
The MAST protocol only provides for controlled and protected
exchange of address lists. The utility of these lists hinges on
their integration into host networking stack services.
8.1. Typical Transport Interfacing
This discussion considers addition of MAST to an existing
Internet protocol stack. It is possible to integrate MAST more
tightly and efficiently, but this is not an immediate concern for
early adoption of the service.
JB> Do you mean rapid prototyping for proof of concept which is long
before early adoption.
MAST must be added to a host implementation of Internet Protocol
and associated transport services, in a way that is transparent
to the IP module and the transport modules. It is injected
between IP and transport. Interfacing to IP transparently is
straightforward.
JB> As implementor that is not clear to me from this spec?
For classic transport services that use IP addresses, it is
necessary to present a single, consistent address during the life
of the association. When MAST is invoked after the start of a
transport association, the transport service will already have a
particular address that it associates with the other participant.
In this case, it is easiest to map the packets being handed up to
the transport layer, from additional addresses into the original
one.
JB> I can guess ok. Are you saying this is a call out to inject as
you say above in the stack? I could argue this could be done
in user space too. But not now.
Another approach is to make all destination addresses appear to
the transport service as coming from an internally allocated
address, such as one allocated in [PRIV]. A networking software
stack would use public IP addresses for rendezvous functions, but
transport would re-use addresses from this private, internal
address space.
JB> Yuck. Thats putting NAT into my stack. I don't think so Dave.
8.2. MAST through NAT
Network Address Translation [NAT] devices map one address space
into another, typically between an intranet set of host addresses
to a smaller set of Internet addresses. In effect, they use port
numbers as a means of mapping internal hosts to the smaller set
of external addresses.
This causes problems for any transport that performs end-system
calculations that using IP addresses. The end system does the
calculations on one set of addresses, but the NAT device changes
an address, so that the calculation by the receiving party will
not be correct. Hence, NAT devices also need to know about
transport-level use of IP addresses and must adjust the values
for those calculations carried in transport (or above) headers.
MAST exacerbates this situation, since the mapping between IP
address and transport calculations is more complicated. Whereas
there used to be only one IP address to worry about, now there
can be more.
Note the section 4.3 specification of the "probe" operation, to
discover NAT transformation on the sender's address.
JB> No comment hopefully NAT is dead with IPv6 for most cases.
8.3. MAST Agent
Multihoming is often a feature of a network, rather than a host.
Hosts often do not know that there are multiple Internet
connections, especially when the local network uses internal
(private) addressing that is different from the network's public
address.
In these cases, it might be possible for MAST to be implemented
as a feature of the local network's NAT function, rather than in
the end-system. Since the NAT is already doing address
translation, adding MAST only requires that the NAT query the
other end of the communication, to obtain permission to add MAST
exchanges and multiple addresses.
Appendix
A.1. Acknowledgements
A.2. References
A.3. Author's Adress
A.4. Full Copyright Statement
JB> Please have page numbers for the TOC
1. INTRODUCTION
"We need a way for sites to be internally stable even
when their relationship to the world around them
changes for whatever reason."
-- E. Lear
JB> I disagree. Chaos is the natural order of things, trying to make things
stable in nature mutates natures purpose and pollutes the planet earth
with all sorts of problems we later deal with. It is better to adapt to
chaos through proceses that accept the chaos. Same for networking.
An IP Address serves as references to a "place" on the Internet
and to a host on the Internet. These two roles are generally
labeled "locator" and "identifier", respectively. Systems that
use IP Addresses as identifiers typically cannot support dynamic
changes in the mapping between the identifier and the locator.
For example, TCP includes a single source/destination IP Address
pair in its definition of a connection. Hence its transport
association is tied to that pair. This is problematic for hosts
that are multihomed or mobile. Both have access to multiple IP
Addresses, but they are prevented from using more than one within
an existing context, because the context is named by that pair.
For a system to use a different IP Address pair, participants
must initiate a new exchange. In the case of TCP, this means a
new connection.
JB> Mobile is wide topic suggest you remove this from the introduction.
In recent years, there have been efforts to overcome this
limitation, through different approaches at different places in
the Internet architecture. Some approaches modify the IP
infrastructure, with embedded redirection services. Some define
transport enhancements to support a set of locators directly, and
some define a layer between classic IP and classic transport. The
primary goal of these multiaddressing efforts is to preserve
established connections when an IP Address changes. Each of the
existing proposals has notable limitations in functionality,
implementation, deployment or use.
JB> Exactly which problems and which ones were addressed please.
This paper reviews the basic requirements for support of
multiaddressing (mobility and multihoming), and the efforts to
support them. Barriers to adoption, administrative overhead, and
operational efficiency are of particular concern. In addition,
the analysis considers enhanced functionality that is possible
from the use of multiaddressing, such as performance-based load-
sharing, across the different locators available to a multihomed
host.
JB> Remove mobility above and stick to multihoming.
1.1. Scenarios
What are the situations and concerns that affect design and use
of a mechanism for the support of multiaddressing?
Section 3 of [MOBMH], has an excellent discussion of these
issues.
It is included here by reference without section 3.2.
Section 3.2 covers an interesting topic that appears to be
independent of multiaddressing.
The included text comprises the following sub-
sections:
3. Usage scenarios
3.1 End-host mobility
3.2 Location privacy à
3.3 End-host multi-homing
3.4 Site multi-homing
3.5 Combined mobility and multi-homing
3.6 Network renumbering
3.7 Combined all
JB> Spec should put this in the spec or discuss it more than
justn reference.
1.2. IETF Background
Historically, IETF focus on mobility has split between initial
attachment configurations, into an otherwise static environment
such as by using DHCP, versus forwarding mechanisms, such as by
modifying the IP infrastructure with Mobile IP. Multihoming has
largely been ignored, except in routing protocol work. Recent
efforts are pursuing direct enhancements to transport or
insertion of a mapping layer between IP and transport. There has
also been adjunct activity, relevant to this topic.
The following summary of IETF activities draws on text from the
Abstracts of documents for those activities. In addition, there
is a useful analysis of the different architectural and protocol
efforts is in Section 3, "Internet Stack Placement" in [NSRG].
Specification efforts are discussed in more detail in Section
The Name Space Research Group [NSRG] considered
modifications to the Internet architecture, including
whether an additional level of naming is needed, above layer
3 but below the application layer. Purpose-Built Keys [PBK]
specifies a template for the use of specially generated
public/private key pairs, to provide assurance that
successive messages in the communication come from the same
source. This is accomplished without the use of external
certification authorities. Hence it ensures authentic
continuity during a session, but does not provide "global"
or "absolute" authentication.
Stream Control Transmission Protocol [SCTP] is a reliable
transport protocol for multiplexed data streams. It
includes modern mechanisms for safe initiation of a
connection, as well as the necessary tools for reliability
and congestion control. It also has a mechanism for
communication access to multiple IP Addresses between the
participation host pair. [TCP-MH] uses TCP options to
support multihoming. Datagram Congestion Control Protocol
[DCCP] is a proposal for a network-friendly, unreliable
transport-level datagram delivery service.
Mobile IP work has divided between IPv4 and IPv6. [MIP4] and
[MIP6] allow a node to continue using its "permanent" home
address as it moves around the internet.
Host Identity Protocol [HIP] is used to establish a rapid
authentication between two hosts and to provide continuity
of communications between those hosts independent of the
networking layer. The [LIN6] protocol defines a layer that
supports multiple locators, between IPv6 and transport.
Multiple Address Service for Transport [MAST] supports
association of multiple IP Addresses during the life of any
transport instantiation, by defining a layer between IP and
transport. It operates only in the endpoints and works with
IPv4 and IPv6.
JB> Your point is?
1.3. Discussion Venue
Discussion and commentary are encouraged about the topics
presented in this document. The preferred forum is the
<mailto:multi6@ops.ietf.org> mailing list, for which archives and
subscription information are available at
<http://ietf.org/html.charters/multi6-charter.html>.
NOTE: The early drafts of a review document, like this,
are certain to have significant errors. The
author strongly requests guidance for clarifying
and correcting any problematic text.
In particular, those working on the proposals and
specifications discussed here are encouraged to
provide corrections and additional text, to
ensure accuracy.
1.4. Document History
-00 Derived from draft-crocker-mast-proposal-00.
Extended discussions about alternative proposals
and architectural issues, separated from the -
proposal- draft.
-01 Substantial revisions to all sections. More
complete review of efforts. More extensive
terminology definitions. Section 3 renamed to
"Considerations". Material that evaluates
proposals is moved out of it, to the next
section.
Later versions need cleaner separation of topics,
such as requirements and definition of what multi-
addressing support really means in different
situations.
Need to add a chart that compares the proposals.
Need to incorporate the remainder of Marcelo's
suggested changes.
Need to discuss enhancements made possible by
multiaddressing support.
NOTE: D. Crocker has put forward the MAST proposal.
That may have colored the perspectives in this
discussion paper.
2. TERMINOLOGY
This paper discusses requirements and methods for enabling an
endpoint to use multiple locators during single application
associations. This topic does not yet have a stable, core set of
terms in general use. The following definitions are intended to
remedy that deficiency; they are taken from existing definitions,
when available. Work on multiaddress enhances existing
infrastructure capabilities. This work is uncovering ambiguities
to terms that have been used. For multiaddressing, it is
therefore confusing to use some common terms, notably "address".
Hence they SHOULD NOT be used.
2.1. Recommended
Agent refers to a third-party that is handling
something on behalf of one or more other
parties. The term indicates the separateness
of the entity, as well as its key
relationship to the other entities. In
multiaddressing, it refers to an intermediary
service that represents an endpoint, for the
purposes of referral and/or relaying.
Association refers to an established communication
context between endpoints, such as a TCP
connection.
Endpoint refers to "the fundamental agent of end-end
communication" [EID]. It is an end-system
that participates in an association.
Endpoints are distinguished from
intermediate, infrastructure nodes and hosts.
JB> Not clear all agree EID == this definition? Is referencing EID
correct here?
Identifier refers to a unique label for an endpoint. The
label is used simply for distinguishing one
endpoint from another. Because a locator is
usually globally unique, it might be able to
serve as an identifier. However this use will
often suffer administrative and referential
limitations as a global identifier for mobile
endpoints. This is exemplified by the current
problems experienced with the dual role of IP
Addresses.
Initiator refers to an endpoint that initiates contact
with a target endpoint. In client/server
architecture it is the client.
IP Address specifies a topological network access point.
The term is usually considered to specify an
endpoint interface. However discussions
about mobility are notably clarified by
viewing the value as belonging to the network
(interface) rather than to the endpoint.
Locator refers to a "the name of a network attachment
point" [SALT], usually in terms of the
network's topology. Locators typically
facilitate mapping into routes, such as by
indicating a topological hierarchy. IP
Addresses specify a topological network
access point. They usually are considered to
specify an endpoint interface. However
discussions about mobility are enhanced by
viewing the value as belonging to the network
(interface) rather than to the endpoint.
Mobility refers to an endpoint's having different
locators over time. This may even include
discontinuities, during which an endpoint has
no valid locators. In addition, the nature of
a transition from one locator to another may
include overlapping availability of locators.
Interestingly, this looks the same as
multihoming. Mobility may be for a single
endpoint or for the subnetwork to which the
endpoint is attached. In the latter case, the
endpoint connection is stable, with respect
to its sub-network, but the sub-network
propogates connectivity change information to
the endpoint.
Multiaddressing refers to an endpoint's having more than one
locator available, over the lifetime of an
association. It encompasses both multihoming
and mobility. The core requirement for
multiaddressing is preservation of
established communications, across the use of
different locators.
JB> This is what MAST should be focusing on or change the name of the effort.
Multihoming refers to the availability of multiple
endpoint locators at the same endpoint,
simultaneously. It is typically used to refer
to multiple network attachments for a host,
but works equally well for multiple upstream
network attachments by the local network,
when the different upstream locators are
visible to the host. Interestingly,
multihomed environments often must support
dynamic changes, such as when adding a new
upstream provider. Therefore, multihoming can
include mobility features and mobility can
include multihoming features. When needing to
renumber a network, due to changes in up-
stream service, the process can be operated
as dynamic multihoming.
Path discovery provides a sender with the means for learning
about the locators from which they can send.
Path selection is required when more than one locator is
available to the sender. Although the sender
is limited to specifying an locator, rather
than a path, it appears that thinking of it
as path selection aids consideration of
solutions. In effect, it formulates the
selection task as being similar to the job of
routers. Route formulation is mature
technology, so that this aspect of
multiaddress processing will be tractable, if
not straightforward.
Referral permits an initiator to obtain a locator for
a target, such as a client being referred to
a server. A third-party process is required
for referral, in the absence of an
association. For existing associations,
participating endpoints might be able to
supply their own referrals. The primary
Internet mechanism for referral has been the
Domain Name Service (DNS). The DNS uses
long, variable-length strings (names) and is
tailored for large-scale referral with
identifiers and locators (mappings) that
change infrequently.
Referral Agent refers to the function that maintains the
mapping between a mobile node's identifier
and its locator(s). [LIN6] calls this a
Mapping Agent.
Rehoming refers to an endpoint's changing an
association from one locator to another,
Relaying refers to the redirection of packets, on
behalf of an endpoint. Other endpoints see a
stable locator for the endpoint obtaining the
relaying service.
Relaying Agent refers to an agent that performs packet
forwarding (relaying) on behalf of an
endpoint. The Relaying Agent thereby
persents a stable locator to the Internet,
for the endpoint. For mobility, the agent
resides on an endpoint's "home" network and
relays datagrams to the endpoint's actual
location on the Internet. The endpoint is
modified to support this forwarding
technique.
Rendezvous refers to one endpoint making contact with an
explicitly identified other endpoint.
Target refers to an endpoint that receives contact
from an Initiator endpoint. In a
client/server architecture, this is the
server.
JB> I have issues with some of the definitions. I suggest a draft all by it
self to define terms and remove MAST from the title call it something else.
Be a good multi6 draft too.
2.2. Deprecated
Address Refers to "the name of some network
attachment point." [SALT] The term has become
a problematic because addresses often are
used for two, distinct functions. Hence the
term should not be used by itself, for these
discussions, except with reference to
particular protocol specifications, such as
"IP Address". Instead, use "identifer" and
"locator", as appropriate.
Connection A state of association between two endpoints.
Because the term is typically used for to
refer to transport-layer state, discussions
about multiaddressing should use the more
general term "association", except with
reference to particular protocol
specification, such as "TCP Connection".
JB> I don't support this until we do previous response and a lot of work.
3. CONSIDERATIONS
The core requirement for multiaddressing is continuity of access
within an association. However applications having this as a
compelling requirement have not yet been evident on the Internet.
Hence there ius some risk that proposed mechanisms to solve the
requirement will not correctly ancitipate the details of the
requirement.
This section is a general discussion of requirements, constraints
and concerns. It does not attempt to offer a formal set of
requirements or recommendations.
3.1. Mobility
Mobility is time-varying access to multiple locators for the same
endpoint. Key parameters to mobility are scope of change, rate of
change and source(s) of the change. Over what portion of the
Internet topology might a change take place; how often will
changes occur; and which of the participants will change their
locators?
JB> Out of scope and charter for multi6. Take this to ADs and find out
where this discussion belongs I am not sure but its not mulit6.
3.1.1. Rapid, Local Initiators
It is generally accepted that rapid, local changes should be
handled by a layer below IP. These changes are therefore
invisible to IP and above, so that associations are automatically
preserved across change.
3.1.2. Rare, Distant Initiators
For initiator endpoints that are subject to occasional detachment
and eventual reconnection, the current set of technologies is
probably sufficient. These require reconfiguration, such as
through DHCP, and establishing new associations. Applications
wishing to retain association state, across these transitions, do
so above the transport layer. They are capable of establishing
new transport associations, as needed.
3.1.3. Periodic, Moderate
What is missing from the operational Internet is support for
initiator and target systems that move over the course of minutes
or hours and need to maintain existing transport associations or
need to maintain their availability for new associations.
The difference between mobility prior to initial contact and
mobility during an existing association is significant. In the
latter case, the mobile host can use the association state when
needing to inform the other endpoint about the change. Prior to
an association -- or when both endpoints are mutually mobile --
an independent referral service is required.
The difference between initiator mobility and target mobility is
also significant, with respect to initial contact. In particular
the initiator needs to be able to obtain a valid locator for the
target. Again, this requires a referral mechanism, such as having
the routing system map from identifiers to routes, rather than
locators to routes. Either it must be provided implicitly within
the network or there must be an external "referral" mechanism.
For static servers, the DNS already provides this referral quite
well. However current DNS use does not support frequent locator
changes over short periods. Hence enhancements are needed to
support referral with a mobile target.
JB> Out of scope for multi6 not sure where it belongs in IETF off
the top of my head.
JB> No other comments. This spec does not discuss other choices to MAST
but discusses multi6 issues it should be renamed and called mutli6 terms
analysis and multi6 IP architecture analysis.