draft-ietf-mboned-ssmping-04.txt   draft-ietf-mboned-ssmping-05.txt 
Network Working Group S. Venaas Network Working Group S. Venaas
Internet-Draft UNINETT Internet-Draft UNINETT
Intended status: Informational February 21, 2008 Intended status: Informational September 18, 2008
Expires: August 24, 2008 Expires: March 22, 2009
Multicast Ping Protocol Multicast Ping Protocol
draft-ietf-mboned-ssmping-04 draft-ietf-mboned-ssmping-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 24, 2008. This Internet-Draft will expire on March 22, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract Abstract
The Multicast Ping Protocol specified in this document allows for The Multicast Ping Protocol specified in this document allows for
checking whether an endpoint can receive multicast, both Source- checking whether an endpoint can receive multicast, both Source-
Specific Multicast (SSM) and Any-Source Multicast (ASM). It can also Specific Multicast (SSM) and Any-Source Multicast (ASM). It can also
be used to obtain additional multicast related information like be used to obtain additional multicast related information like
multicast tree setup time etc. This protocol is based on an multicast tree setup time etc. This protocol is based on an
implementation of tools called ssmping and asmping. implementation of tools called ssmping and asmping.
skipping to change at page 2, line 23 skipping to change at page 2, line 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol specification . . . . . . . . . . . . . . . . . . . . 4 3. Protocol specification . . . . . . . . . . . . . . . . . . . . 4
3.1. Option format . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Option format . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Defined Options . . . . . . . . . . . . . . . . . . . . . 6 3.2. Defined Options . . . . . . . . . . . . . . . . . . . . . 6
4. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Message types and options . . . . . . . . . . . . . . . . . . 11 5. Message types and options . . . . . . . . . . . . . . . . . . 11
6. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 12 6. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 12
7. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 14 7. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 14
8. Recommendations for Implementers . . . . . . . . . . . . . . . 15 8. Recommendations for Implementers . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
11. Security Considerations . . . . . . . . . . . . . . . . . . . 16 11. Security Considerations . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
12.1. Normative References . . . . . . . . . . . . . . . . . . . 17 12.1. Normative References . . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . . 17 12.2. Informative References . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 18
1. Introduction 1. Introduction
skipping to change at page 6, line 24 skipping to change at page 6, line 24
Version, type 0 Version, type 0
Length MUST be 1. This option MUST always be included in all Length MUST be 1. This option MUST always be included in all
messages, and the value MUST be set to 2 (in decimal). Note messages, and the value MUST be set to 2 (in decimal). Note
that there are older implementations of ssmping that only that there are older implementations of ssmping that only
partly follow this specification. They can be regarded as partly follow this specification. They can be regarded as
version 1 and do not use this option. If a server receives a version 1 and do not use this option. If a server receives a
message with a version other than 2 (or missing), the server message with a version other than 2 (or missing), the server
SHOULD (unless it supports the particular version) send a SHOULD (unless it supports the particular version) send a
Response message back with version set to 2. Client ID and Response message back with version set to 2. Client ID and
Sequence Number options should be echoed if present. It SHOULD Sequence Number options SHOULD be echoed if present. It SHOULD
not include any other options. A client receiving a response not include any other options. A client receiving a response
with a version other than 2, MUST (unless it supports the with a version other than 2, MUST (unless it supports the
particular version), stop sending requests to the server. particular version), stop sending requests to the server.
Client ID, type 1 Client ID, type 1
Length MUST be non-zero. A client SHOULD always include this Length MUST be non-zero. A client SHOULD always include this
option in all messages (both Init and Request). The client may option in all messages (both Init and Request). The client may
use any value it likes to be able to detect whether a reply is use any value it likes to be able to detect whether a reply is
a reply to its Init/Request or not. A server should treat this a reply to its Init/Request or not. A server should treat this
as opaque data, and simply leave it unchanged in the reply as opaque data, and MUST echo this option back in the reply if
(both Server Response and Reply). The value might be a process present (both Server Response and Reply). The value might be a
ID, perhaps process ID combined with an IP address because it process ID, perhaps process ID combined with an IP address
may receive multicast responses to queries from other clients. because it may receive multicast responses to queries from
It is left to the client implementer how to make use of this other clients. It is left to the client implementer how to
option. make use of this option.
Sequence Number, type 2 Sequence Number, type 2
Length MUST be 4. A client MUST always include this in Request Length MUST be 4. A client MUST always include this in Request
messages and MUST NOT include it in Init messages. A server messages and MUST NOT include it in Init messages. A server
replying to a Request message MUST copy it into the Reply (or replying to a Request message MUST copy it into the Reply (or
Server Response message on error). This contains a 32 bit Server Response message on error). This contains a 32 bit
sequence number. The values would typically start at 1 and sequence number. The values would typically start at 1 and
increase by one for each request in a sequence. increase by one for each request in a sequence.
skipping to change at page 7, line 16 skipping to change at page 7, line 16
Length MUST be 8 bytes. A client SHOULD include this in Length MUST be 8 bytes. A client SHOULD include this in
Request messages and MUST NOT include it in Init messages. A Request messages and MUST NOT include it in Init messages. A
server replying to a Request message MUST copy it into the server replying to a Request message MUST copy it into the
Reply. The timestamp specifies the time when the Request Reply. The timestamp specifies the time when the Request
message is sent. The first 4 bytes specify the number of message is sent. The first 4 bytes specify the number of
seconds since the Epoch (0000 UTC Jan 1, 1970). The next 4 seconds since the Epoch (0000 UTC Jan 1, 1970). The next 4
bytes specify the number of microseconds since the last second bytes specify the number of microseconds since the last second
since the Epoch. since the Epoch.
Multicast group, type 4 Multicast Group, type 4
Length MUST be greater than 2. It MAY be used in Server Length MUST be greater than 2. It MAY be used in Server
Response messages to tell the client what group to use in Response messages to tell the client what group to use in
subsequent Request messages. It MUST be used in Request subsequent Request messages. It MUST be used in Request
messages to tell the server what group address to respond to messages to tell the server what group address to respond to
(this group would typically be previously obtained in a Server (this group would typically be previously obtained in a Server
Response message). It MUST be used in Reply messages (copied Response message). It MUST be used in Reply messages (copied
from the Request message). It MUST NOT be used in Init from the Request message). It MUST NOT be used in Init
messages. The format of the option value is as below. messages. The format of the option value is as below.
skipping to change at page 10, line 7 skipping to change at page 10, line 7
'wildcard'. The group address need only contain enough octets 'wildcard'. The group address need only contain enough octets
to cover the prefix length bits (i.e., the group address would to cover the prefix length bits (i.e., the group address would
have to be 3 octets long if the prefix length is 17-24, and have to be 3 octets long if the prefix length is 17-24, and
there need be no group address for the wildcard with prefix there need be no group address for the wildcard with prefix
length 0). Any bits past the prefix length MUST be ignored. length 0). Any bits past the prefix length MUST be ignored.
For IPv4, the option value length will be 4-7, while for IPv6, For IPv4, the option value length will be 4-7, while for IPv6,
it will be 4-19, and for the wildcard, it will be 3. it will be 4-19, and for the wildcard, it will be 3.
Session ID, type 11 Session ID, type 11
Length MUST be non-zero. A server MAY include this in Server Length MUST be non-zero. A server SHOULD include this in
Response and Reply messages. If a client receives this option Server Response and Reply messages. If a client receives this
in a message, the client MUST echo the Session ID option in option in a message, the client MUST echo the Session ID option
subsequent Request messages, with the exact same value, until in subsequent Request messages, with the exact same value,
the next message is received from the server. If the next until the next message is received from the server. If the
message from the server has no Session ID or a new Session ID next message from the server has no Session ID or a new Session
value, the client should do the same, either not use the ID value, the client should do the same, either not use the
Session ID, or use the new value. The Session ID may help the Session ID, or use the new value. The Session ID may help the
server in keeping track of clients and possibly manage per server in keeping track of clients and possibly manage per
client state. It is left to the server implementer to decide client state. The value of a new Session ID should be chosen
whether it is useful and how to make use of it. pseudo randomly so that it is hard to predict. This can be
used to prevent spoofing of the source address of Request
messages, see the Security Considerations for details.
Server Timestamp, type 12 Server Timestamp, type 12
Length MUST be 8 bytes. A server supporting this option, Length MUST be 8 bytes. A server supporting this option,
SHOULD include it in Reply messages, if requested by the SHOULD include it in Reply messages, if requested by the
client. The timestamp specifies the time when the Reply client. The timestamp specifies the time when the Reply
message is sent. The first 4 bytes specify the number of message is sent. The first 4 bytes specify the number of
seconds since the Epoch (0000 UTC Jan 1, 1970). The next 4 seconds since the Epoch (0000 UTC Jan 1, 1970). The next 4
bytes specify the number of microseconds since the last second bytes specify the number of microseconds since the last second
since the Epoch. since the Epoch.
skipping to change at page 13, line 9 skipping to change at page 13, line 14
the unicast address of the server. It can then send an Init message the unicast address of the server. It can then send an Init message
with a prefix option containing the desired address family and zero with a prefix option containing the desired address family and zero
prefix length (wildcard entry). The server is then free to decide prefix length (wildcard entry). The server is then free to decide
which group, from the specified family, it should return. A client which group, from the specified family, it should return. A client
may also allow a user to specify group address(es) or prefix(es) (for may also allow a user to specify group address(es) or prefix(es) (for
IPv6, the user may only be required to specify a scope or an RP IPv6, the user may only be required to specify a scope or an RP
address, from which the client can construct the desired prefix, address, from which the client can construct the desired prefix,
possibly embedded-RP). From this the client can specify one or more possibly embedded-RP). From this the client can specify one or more
prefix options in an Init message to tell the server which address it prefix options in an Init message to tell the server which address it
would prefer. If the user specifies a group address, that can be would prefer. If the user specifies a group address, that can be
encoded as a prefix of maximal length (e.g. 32 for IPv4). The prefix encoded as a prefix of maximal length (e.g., 32 for IPv4). The
options are in prioritised order, i.e., the client should put the prefix options are in prioritised order, i.e., the client should put
most preferred prefix first. the most preferred prefix first.
If the client receives a Server Response message containing a group If the client receives a Server Response message containing a group
address it can start sending Request messages, see the next address it can start sending Request messages, see the next
paragraph. If there is no group address option, it would typically paragraph. If there is no group address option, it would typically
exit with an error message. The server may have included some prefix exit with an error message. The server may have included some prefix
options in the Server Response. The client may use this to provide options in the Server Response. The client may use this to provide
the user some feedback on what prefixes or scopes are available. the user some feedback on what prefixes or scopes are available.
Assuming the client got a group address in a Server Response, it can Assuming the client got a group address in a Server Response, it can
start pinging. Before it does that, it should let the user know start pinging. Before it does that, it should let the user know
skipping to change at page 14, line 16 skipping to change at page 14, line 21
7. Server Behaviour 7. Server Behaviour
We will consider how a typical server using the above protocol would We will consider how a typical server using the above protocol would
behave. First we consider how to respond to Init messages. If the behave. First we consider how to respond to Init messages. If the
Init message contains prefix options, the server should look at them Init message contains prefix options, the server should look at them
in order and see if it can assign a multicast address from the given in order and see if it can assign a multicast address from the given
prefix. The server would be configured, possibly have a default, prefix. The server would be configured, possibly have a default,
specifying which groups it can offer. It may have a large pool just specifying which groups it can offer. It may have a large pool just
picking a group at random, possibly choose a group based on hashing picking a group at random, possibly choose a group based on hashing
of the clients IP address or identifier, or just use a fixed group. of the client's IP address or identifier, or just use a fixed group.
It is left to the server to decide whether it should allow the same A server could possibly decide whether to include site scoped group
address to be used simultaneously by multiple clients. If the server ranges based on the client's IP address. It is left to the server to
finds a suitable group address, it returns this in a group option in decide whether it should allow the same address to be used
a Server Response message. The server may additionally include a simultaneously by multiple clients. If the server finds a suitable
Session ID. This may help the server if it is to keep some state, group address, it returns this in a group option in a Server Response
for instance for making sure the client uses the group it got message. The server should additionally include a Session ID. This
assigned. A good Session ID would be a random byte string that is may help the server if it is to keep some state, for instance for
hard to predict. If the server cannot find a suitable group address, making sure the client uses the group it got assigned. A good
or if there were no prefixes in the Init message, it may send a Session ID would be a pseudo random byte string that is hard to
Server Response message containing prefix options listing what predict. If the server cannot find a suitable group address, or if
prefixes may be available to the client. Finally, if the Init there were no prefixes in the Init message, it may send a Server
message requests the Server Information option, it should include Response message containing prefix options listing what prefixes may
that. be available to the client. Finally, if the Init message requests
the Server Information option, it should include that.
When the server receives a Request message, it may first check that When the server receives a Request message, it may first check that
the group address and Session ID (if provided) are valid. If the the group address and Session ID (if provided) are valid. If the
server is satisfied, it will send a unicast Reply message back to the server is satisfied, it will send a unicast Reply message back to the
client, and also a multicast Reply message to the group address. The client, and also a multicast Reply message to the group address. The
Reply messages contain the exact options and in the same order, as in Reply messages contain the exact options and in the same order, as in
the Request, and after that the server adds a TTL option and the Request, and after that the server adds a TTL option and
additional options if needed. E.g., it may add a timestamp if additional options if needed. E.g., it may add a timestamp if
requested by the client. If the server is not happy with the Request requested by the client. If the server is not happy with the Request
(bad group address or Session ID, request is too large etc), it may (bad group address or Session ID, request is too large etc), it may
skipping to change at page 15, line 30 skipping to change at page 15, line 35
freedom for implementers. In this section we present some freedom for implementers. In this section we present some
recommendations. recommendations.
Server administrators should be able to configure one or multiple Server administrators should be able to configure one or multiple
group prefixes in a server implementation. When deploying servers on group prefixes in a server implementation. When deploying servers on
the Internet and in other environments, the server administrator the Internet and in other environments, the server administrator
should be able to restrict the server to respond to only a few should be able to restrict the server to respond to only a few
multicast groups which should not be currently used by multicast multicast groups which should not be currently used by multicast
applications. A server implementation should also provide applications. A server implementation should also provide
flexibility for an administrator to apply various policies to provide flexibility for an administrator to apply various policies to provide
one or multiple group prefixes to specific clients. One such policy one or multiple group prefixes to specific clients, e.g., site scoped
could be to use the client IP address if it can be trusted. addresses for clients that are inside the site. Clients could be
identified by their IP address provided that clients are required to
send Init messages, and they receive an unpredictable Session ID.
Servers must perform rate limiting, to guard against this protocol Servers must perform rate limiting, to guard against this protocol
being used for DoS attacks. By default, clients should send at most being used for DoS attacks. By default, clients should send at most
one request per second, and servers should perform rate limiting if a one request per second, and servers should perform rate limiting if a
client sends more frequent requests. Server implementations should client sends more frequent requests. Server implementations should
provide administrative control of which client IP addresses to serve, provide administrative control of which client IP addresses to serve,
and may also allow certain clients to perform more rapid requests. and may also allow certain clients to perform more rapid requests.
Implementers of applications/tools using this protocol should Implementers of applications/tools using this protocol should
consider the UDP guidelines [6], in particular if clients are to consider the UDP guidelines [6], in particular if clients are to
send, or servers are to accept, requests at rates exceeding one per send, or servers are to accept, requests at rates exceeding one per
skipping to change at page 16, line 44 skipping to change at page 17, line 5
There are some security issues to consider. One is that a host may There are some security issues to consider. One is that a host may
send a request with an IP source address of another host, and make an send a request with an IP source address of another host, and make an
arbitrary multicast ping server on the Internet send packets to this arbitrary multicast ping server on the Internet send packets to this
other host. This behaviour is fairly harmless. The worst case is if other host. This behaviour is fairly harmless. The worst case is if
the host receiving the unicast replies also happen to be joined to the host receiving the unicast replies also happen to be joined to
the multicast group used. In this case, there would be an the multicast group used. In this case, there would be an
amplification effect where the host receives twice as many replies as amplification effect where the host receives twice as many replies as
there are requests sent. there are requests sent.
In order to help prevent spoofing, a server SHOULD require the client
to send an Init message, and return an unpredictable Session ID in
the response. The ID should be associated with the IP address and
have a limited lifetime. The server SHOULD then only respond to
Request messages that have a valid Session ID associated with the
source IP address of the Request.
Server implementations should allow administrators to restrict which Server implementations should allow administrators to restrict which
groups a server responds to, and also perform rate limiting. This is groups a server responds to, and also perform rate limiting. This is
discussed in Section 8). discussed in Section 8).
12. References 12. References
12.1. Normative References 12.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 17, line 24 skipping to change at page 17, line 37
Specification", RFC 2460, December 1998. Specification", RFC 2460, December 1998.
[4] "IANA, Address Family Numbers", [4] "IANA, Address Family Numbers",
<http://www.iana.org/assignments/address-family-numbers>. <http://www.iana.org/assignments/address-family-numbers>.
12.2. Informative References 12.2. Informative References
[5] "ssmping implementation", [5] "ssmping implementation",
<http://www.venaas.no/multicast/ssmping/>. <http://www.venaas.no/multicast/ssmping/>.
[6] Eggert, L. and G. Fairhurst, "UDP Usage Guidelines for [6] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for
Application Designers", draft-ietf-tsvwg-udp-guidelines-05 (work Application Designers", draft-ietf-tsvwg-udp-guidelines-10 (work
in progress), February 2008. in progress), August 2008.
Author's Address Author's Address
Stig Venaas Stig Venaas
UNINETT UNINETT
Trondheim NO-7465 Trondheim NO-7465
Norway Norway
Email: venaas@uninett.no Email: venaas@uninett.no
skipping to change at page 18, line 44 skipping to change at line 813
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 15 change blocks. 
48 lines changed or deleted 56 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/