draft-ietf-dna-routers-01.txt   draft-ietf-dna-routers-02.txt 
DNA Working Group S. Narayanan DNA Working Group S. Narayanan
Internet-Draft Panasonic Internet-Draft Panasonic
Expires: April 26, 2006 G. Daley Expires: September 7, 2006 G. Daley
Monash University CTIE Monash University CTIE
N. Montavont N. Montavont
LSIIT - ULP GET - ENST Bretagne
Oct 23, 2005 March 6, 2006
Detecting Network Attachment in IPv6 - Best Current Practices for Detecting Network Attachment in IPv6 - Best Current Practices for
Routers Routers
draft-ietf-dna-routers-01.txt draft-ietf-dna-routers-02.txt
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 38 skipping to change at page 1, line 38
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 April 26, 2006. This Internet-Draft will expire on September 7, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
Hosts experiencing rapid link-layer changes may require to do Hosts experiencing rapid link-layer changes may require to do
configuration change detection procedures more frequently than configuration change detection procedures more frequently than
traditional fixed hosts. This document describes practices available traditional fixed hosts. This document describes practices available
to network deployers in order to support such hosts in Detecting to network deployers in order to support such hosts in Detecting
Network Attachment in IPv6 networks. Network Attachment in IPv6 networks.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terms and Abbreviations . . . . . . . . . . . . . . . . . 3 1.1 Terms and Abbreviations . . . . . . . . . . . . . . . . . 3
1.2 Relevant Host Issues . . . . . . . . . . . . . . . . . . . 4 1.2 Relevant Host Issues . . . . . . . . . . . . . . . . . . . 4
1.3 Relevant Router Issues . . . . . . . . . . . . . . . . . . 4 1.3 Relevant Router Issues . . . . . . . . . . . . . . . . . . 4
1.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4 Applicability statement . . . . . . . . . . . . . . . . . 5
2. Configuration Practices for DNAv6 Routers . . . . . . . . . . 5 2. Configuration Practices for DNAv6 Routers . . . . . . . . . . 5
2.1 Multicast and Unicast RA Responses . . . . . . . . . . . . 5 2.1 Multicast and Unicast RA Responses . . . . . . . . . . . . 5
2.1.1 Recommendations . . . . . . . . . . . . . . . . . . . 7 2.1.1 Recommendations . . . . . . . . . . . . . . . . . . . 7
2.2 Router Advertisement Parameters . . . . . . . . . . . . . 7 2.2 Router Advertisement Parameters . . . . . . . . . . . . . 7
2.2.1 Recommendations . . . . . . . . . . . . . . . . . . . 8 2.2.1 Recommendations . . . . . . . . . . . . . . . . . . . 8
2.3 Router Advertisement Options . . . . . . . . . . . . . . . 8 2.3 Router Advertisement Options . . . . . . . . . . . . . . . 8
2.3.1 Recommendations . . . . . . . . . . . . . . . . . . . 9 2.3.1 Recommendations . . . . . . . . . . . . . . . . . . . 9
2.4 Triggered Router Advertisements . . . . . . . . . . . . . 9 2.4 Triggered Router Advertisements . . . . . . . . . . . . . 9
2.5 Split Advertisements . . . . . . . . . . . . . . . . . . . 9 2.5 Split Advertisements . . . . . . . . . . . . . . . . . . . 9
2.6 Router Configurations . . . . . . . . . . . . . . . . . . 10 2.6 Router Configurations . . . . . . . . . . . . . . . . . . 10
3. Topological Practices for DNAv6 Networks . . . . . . . . . . . 10 3. Topological Practices for DNAv6 Networks . . . . . . . . . . . 10
3.1 Link Extent and Composition . . . . . . . . . . . . . . . 10 3.1 Link Extent and Composition . . . . . . . . . . . . . . . 10
3.2 Multiple Router Links . . . . . . . . . . . . . . . . . . 10 3.2 Multiple Router Links . . . . . . . . . . . . . . . . . . 11
3.3 Point-to-point Links . . . . . . . . . . . . . . . . . . . 11 3.3 Point-to-point Links . . . . . . . . . . . . . . . . . . . 11
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
4.1 Providing Router Authorization . . . . . . . . . . . . . . 12 4.1 Providing Router Authorization . . . . . . . . . . . . . . 12
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1 Normative References . . . . . . . . . . . . . . . . . . . 12 5.1 Normative References . . . . . . . . . . . . . . . . . . . 12
5.2 Informative References . . . . . . . . . . . . . . . . . . 13 5.2 Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
A. Summary of Recommendations . . . . . . . . . . . . . . . . . . 14 A. Summary of Recommendations . . . . . . . . . . . . . . . . . . 14
skipping to change at page 3, line 19 skipping to change at page 3, line 19
mobile. The frequency of configuration change for wireless and mobile. The frequency of configuration change for wireless and
nomadic devices are elevated, due to the vagaries of wireless nomadic devices are elevated, due to the vagaries of wireless
propagation or the motion of the hosts themselves. propagation or the motion of the hosts themselves.
Such hosts need to determine if they have moved to a new IPv6 link Such hosts need to determine if they have moved to a new IPv6 link
rapidly, in order that configuration procedures may be run and rapidly, in order that configuration procedures may be run and
application packet delivery services restored. Detecting Network application packet delivery services restored. Detecting Network
Attachment (DNA) is a strategy to assist such configuration changes Attachment (DNA) is a strategy to assist such configuration changes
by rapidly determining whether they are required. by rapidly determining whether they are required.
Several network-side factors may impact on the effectiveness and Several network-side factors may impact the effectiveness and speed
speed of DNA procedures. This document provides guidelines embodying of DNA procedures. This document provides guidelines embodying the
the best current practice for network deployers wishing to support best current practice for network deployers wishing to support
detection of network attachment by IPv6 hosts. detection of network attachment by IPv6 hosts.
It should be noted that many already deployed routers will not It should be noted that many already deployed routers will not
support these recommendations, and that hosts SHOULD NOT rely on support these recommendations, and that hosts SHOULD NOT rely on
their being in place, unless they have particular reason to do so. their being in place, unless they have particular reason to do so.
1.1 Terms and Abbreviations 1.1 Terms and Abbreviations
Access network: A network where hosts are present. Especially, a Access network: A network where hosts are present. Especially, a
network used for the support of visiting wireless hosts. network used for the support of visiting wireless hosts.
skipping to change at page 4, line 25 skipping to change at page 4, line 25
Solicitations (NSs) to known routers for reachability detection Solicitations (NSs) to known routers for reachability detection
purposes. purposes.
The following is a list of critical issues for hosts undertaking link The following is a list of critical issues for hosts undertaking link
change detection in IPv6: change detection in IPv6:
Hosts require Router Advertisements (RAs) rapidly in order to Hosts require Router Advertisements (RAs) rapidly in order to
minimize reconfiguration latencies in the case of link change or minimize reconfiguration latencies in the case of link change or
link failure. link failure.
Host wishes to identify if their current prefix is still valid on Hosts need to identify if their current prefix is still valid on a
a link before the prefix expires. Existing IPv6 Neighbour link before the prefix expires. Existing IPv6 Neighbour Discovery
Discovery procedures make this difficult. If the host can procedures make this difficult. If the host can determine that
determine that the target router is still reachable through a the target router is still reachable through a NS/NA exchange, it
NS/NA exchange, it does not mean that the prefix is still valid. does not mean that the prefix is still valid on that link. This
is because link-local addresses are used for the NS/NA exchange.
Conversely, if host sends an RS, the RA received in response may Conversely, if host sends an RS, the RA received in response may
not contain the prefix of interest for the hosts. not contain the prefix of interest for the hosts.
Hosts wish to detect if a particular router is reachable in order Hosts wish to detect if a particular router is reachable in order
to use it for routing. to use it for routing.
Hosts may require some assurance that a device is actually Hosts may require some assurance that a device is actually
present, and is authorized to act as a router. present, and is authorized to act as a router.
Consideration for these issues underlie the practices recommended in Consideration for these issues underlie the practices recommended in
skipping to change at page 5, line 15 skipping to change at page 5, line 16
incurred by hosts receiving response RAs, which cannot be avoided incurred by hosts receiving response RAs, which cannot be avoided
within current standards [1]. within current standards [1].
As described in Section 2.1, additional delays may occur if As described in Section 2.1, additional delays may occur if
multicast responses are required. multicast responses are required.
Routers should also be careful not to increase the network Routers should also be careful not to increase the network
overhead by frequently transmitting router advertisements (see overhead by frequently transmitting router advertisements (see
Section 2.4). Section 2.4).
Routers should include all advertised prefixes within the same RA Multiple prefixes advertised in different RAs by a single router
and indicate whether a previous advertised prefix is not valid may lead to host configurations errors. It may generate erroneous
anymore. Multiple prefixes advertised in different RAs by a movement detection and/or delay hosts to detect that a prefix is
single router may lead to host configurations errors. not valid anymore.
1.4 Summary 1.4 Applicability statement
The practices embodied in this document are considered to provide The practices embodied in this document are considered to provide
minimal support for hosts wishing to detect network attachment. minimal support for hosts wishing to detect network attachment.
Current work within the DNA working group aims to provide Current work within the DNA working group aims to provide
substantially improved performance for link change detection. substantially improved performance for link change detection.
Existing limitations in base protocols such as IPv6 Neighbour Existing limitations in base protocols such as IPv6 Neighbour
Discovery preclude support of real-time applications in some Discovery preclude support of real-time applications in some
environments. Future deployers and implementers are encouraged to environments. Future deployers and implementers are encouraged to
consider the protocols under development at this time in order to consider the protocols under development at this time in order to
provide a generic service to support hosts detecting change. provide a generic service to support hosts detecting change.
2. Configuration Practices for DNAv6 Routers 2. Configuration Practices for DNAv6 Routers
Routers which are being deployed to support hosts' change detection Routers which are being deployed to aid hosts' change detection
procedures should attempt to use appropriate configurations, which procedures should attempt to use appropriate configurations, which
limit advertisement latency, and provide appropriate service limit advertisement latency, and provide appropriate service
considering the constraints of the deployed access network considering the constraints of the deployed access network
technology. technology.
This section describes several configuration parameters which may This section describes several configuration parameters which may
exist on IPv6 routers, and how their tuning may affect DNA hosts. exist on IPv6 routers, and how their tuning may affect DNA hosts.
2.1 Multicast and Unicast RA Responses 2.1 Multicast and Unicast RA Responses
While IPv6 Neighbour Discovery assumes that responses to While IPv6 Neighbour Discovery assumes that responses to
solicitations will be sent multicast, the specification allows any solicitations will be sent multicast, the specification allows any
router to respond to RS message with a unicast RA if it desires [1]. router to respond to RS message with a unicast RA [1]. Note that the
delay between 0 and MAX_RA_DELAY_TIME is still applicable when a
router responds to a RS with a unicast RA.
The advantage in responding with an unicast RA message is to allow The advantage in responding with an unicast RA message is to allow
the IP host to conclusively infer bi-directional reachability from the IP host to conclusively infer bi-directional reachability from
the RS-RA exchange. Neighbour Discovery does not provide any the RS-RA exchange. Neighbour Discovery does not provide any
mechanism to match multicast RA responses with their solicitation, mechanism to match multicast RA responses with their solicitation,
and therefore it is not possible for the hosts to find out whether at and therefore it is not possible for the hosts to find out whether at
least one of its RS messages was received and processed by the least one of its RS messages was received and processed by the
router. Since unicast RAs are only sent in response to solicitation, router. Since unicast RAs are only sent in response to solicitation,
a host can infer that at least one of its Router Solicitations a host can infer that at least one of its Router Solicitations
reached the router. reached the router.
The dis-advantage in sending unicast RA is that the router will not The dis-advantage in sending unicast RA is that the router will not
be able to aggregate its response for multiple RS messages from be able to aggregate its response for multiple RS messages from
multiple hosts received during the waiting period before RA multiple hosts received during the waiting period before RA
transmission. transmission. Moreover, using unicast RA to respond to RS disables
routers' ability to limit the rate of unicast RA.
For multicast Router Advertisements, a minimum separating delay For multicast Router Advertisements, a minimum separating delay
exists so that these RAs may not be scheduled close to each other. exists so that these RAs may not be scheduled close to each other.
When a host solicits and attempts to schedule a multicast RA within When a host solicits and attempts to schedule a multicast RA within
MIN_DELAY_BETWEEN_RAS (or MinDelayBetweenRAs from Mobile IPv6 [3]) of MIN_DELAY_BETWEEN_RAS (or MinDelayBetweenRAs from Mobile IPv6 [3]) of
the previous multicast Router Advertisement, the scheduling of a the previous multicast Router Advertisement, the scheduling of a
response will be deferred until the minimum separation expires. response will be deferred until the minimum separation expires.
This separation delay does not affect unicast Router Advertisement This separation delay does not affect unicast Router Advertisement
responses. Routers MAY choose to respond to RS messages with a responses. Routers MAY choose to respond to RS messages with a
skipping to change at page 7, line 7 skipping to change at page 7, line 8
In some cases it is not possible to provide unicast responses, since In some cases it is not possible to provide unicast responses, since
solicitations may be sent with an unspecified address, or solicitations may be sent with an unspecified address, or
solicitations do not provide enough link-layer addressing information solicitations do not provide enough link-layer addressing information
to send an unicast response without neighbour discovery exchange. In to send an unicast response without neighbour discovery exchange. In
these cases, a router may need to send multicast responses, even if these cases, a router may need to send multicast responses, even if
the expected delay is greater. the expected delay is greater.
2.1.1 Recommendations 2.1.1 Recommendations
Routers SHOULD respond to a RS message with unicast RS message. Routers SHOULD respond to a RS message with unicast RA message.
Routers SHOULD aggregate RA messages into a multi-cast RA message Routers SHOULD aggregate RA messages into a multi-cast RA message
if more than 3 unicast RA messages are queued for transmission. if more than 3 unicast RA messages are queued for transmission.
Where multiple unicast transmissions for the same destination Where multiple unicast transmissions for the same destination
await transmission, routers MAY remove all transmissions after the await transmission, routers MAY remove all transmissions after the
first without ill-effect. first without ill-effect.
2.2 Router Advertisement Parameters 2.2 Router Advertisement Parameters
Where hosts have changeable connectivity, there may be a number of Where hosts often change their link attachment (e.g., because they
prefixes or routers stored in the host's memory, which are no longer are mobile), there may be a number of prefixes or routers stored in
directly reachable. This additional storage may make movement the host's memory, which are no longer directly reachable. This
detection slower where hosts rapidly pass through networks, or pass additional storage may make movement detection slower where hosts
through networks which have very long advertised timeouts. rapidly pass through networks, or pass through networks which have
very long advertised timeouts.
Routers SHOULD be configured to advertise non-default Valid and Routers SHOULD be configured to advertise non-default Valid and
Preferred lifetimes in order to provide DNA hosts with link-specific Preferred lifetimes in order to provide DNA hosts with link-specific
address lifetime information. address lifetime information.
Administrators are advised to set the advertised Preferred and Valid Administrators are advised to set the advertised Preferred and Valid
timers of prefixes to the maximum duration for which any host may be timers of prefixes to the maximum duration for which any host may be
required to continue functioning without receiving a particular required to continue functioning without receiving a particular
advertised prefix. advertised prefix.
Where hosts with ongoing transactions, or well known services (such Where hosts with long-lifetime communications, or well known services
as DNS) are present on a network, this duration SHOULD be greater (such as DNS) are present on a network, the preferred lifetime SHOULD
than the maximum expected outage time (for example 9 hours for 0.999 be greater than the maximum expected outage time (For example, if the
uptime, with a single outage/year). maximum router outage is 8.72 hours (for 0.999 uptime), the preferred
lifetime could be set to 9 hours, which would be sufficient to
support existing and allow new communications across the failure).
Upon links where fixed hosts are unlikely to be present, Upon links where fixed hosts are unlikely to be present,
administrators SHOULD reduce the Router Lifetime, and Prefix Valid administrators SHOULD reduce the Router Lifetime, and Prefix Valid
and Preferred Lifetimes on routers used to support DNA. and Preferred Lifetimes on routers used to support DNA.
One potential configuration heuristic would be to configure lifetimes One potential configuration heuristic would be to configure lifetimes
to be a low number (for example: 15) of times the MaxRtrAdvInterval, to be a low number (for example: 15) of times the MaxRtrAdvInterval,
or greater than the lower quartile cell residence time of hosts on or greater than the lower quartile cell residence time of hosts on
the network (if known). This allows reuse of configuration in the the network (if known). This allows reuse of configuration in the
case where hosts are moving back and forth rapidly between links, but case where hosts are moving back and forth rapidly between links, but
skipping to change at page 10, line 43 skipping to change at page 10, line 46
Most of today's access networks deploy link-layer bridging Most of today's access networks deploy link-layer bridging
technologies in order to extend their logical range beyond a single technologies in order to extend their logical range beyond a single
Medium Access Control domain. Medium Access Control domain.
Consequently, while many routers will come with traditional wired or Consequently, while many routers will come with traditional wired or
optic-fibre interfaces, packets travelling within the same link may optic-fibre interfaces, packets travelling within the same link may
have been bridged across from a wired segment to a wireless segment. have been bridged across from a wired segment to a wireless segment.
In many of cases, the router will not have accurate information about In many of cases, the router will not have accurate information about
the transmission rates or media of particular segments on the link. the transmission rates or media of particular segments on the link.
When defining the frequency at which RA will be sent over a link,
Routers with interfaces whose technology is bridgeable SHOULD NOT Routers with interfaces whose technology is bridgeable SHOULD NOT
assume that all segments and devices on the link have the same assume that all segments and devices on the link have the same
bandwidth available. bandwidth available.
3.2 Multiple Router Links 3.2 Multiple Router Links
IPv6 Neighbour Discovery allows multiple routers to be advertising on IPv6 Neighbour Discovery allows multiple routers to be advertising on
the same link [1]. These routers are not required to advertise the the same link [1]. These routers are not required to advertise the
same prefixes as each other. This section provides some guidelines same prefixes as each other. This section provides some guidelines
for deploying multiple routers on the same link. for deploying multiple routers on the same link.
skipping to change at page 12, line 4 skipping to change at page 12, line 11
the link. Routers on such point-to-point links MAY avoid the delay the link. Routers on such point-to-point links MAY avoid the delay
by not waiting for the prescribed random time before responding for by not waiting for the prescribed random time before responding for
the Router Solicitation message [8] [14]. the Router Solicitation message [8] [14].
4. Security Considerations 4. Security Considerations
When operating a network in support of hosts performing link change When operating a network in support of hosts performing link change
detection, both the operational security of the hosts and network detection, both the operational security of the hosts and network
infrastructure are important. DNA procedures rely upon rapid infrastructure are important. DNA procedures rely upon rapid
delivery of information to hosts using IPv6 Neighbour Discovery. delivery of information to hosts using IPv6 Neighbour Discovery.
Neighbour Discovery as a critical service in IPv6 networks is subject Neighbour Discovery as a critical service in IPv6 networks is subject
to various attacks as described in [7]. to various attacks as described in [7].
The following sections describe issues and practices to provide The following sections describe issues and practices to provide
additional functional security for both operators and hosts. additional functional security for operators.
4.1 Providing Router Authorization 4.1 Providing Router Authorization
In DNA, some hosts will begin configuration procedures based on a In DNA, some hosts will begin configuration procedures based on a
single message transmitted by a router. As such the ability of single message transmitted by a router. As such the ability of
routing infrastructure to prove its authenticity and authorization is routing infrastructure to prove its authenticity and authorization is
important to support correct operation of hosts. Authentication and important to support correct operation of hosts. Authentication and
authorization mechanisms exist which allow hosts to check security of authorization mechanisms exist which allow hosts to check security of
routers when they receive Router Advertisements indicating link routers when they receive Router Advertisements indicating link
change. change.
Today these mechanisms require additional message exchanges and Today these mechanisms require additional message exchanges and
public key operations to check the authorization chain back to a public key operations to check the authorization chain back to a
trusted root. Considering the computational cost for verifying trusted root. Considering the computational cost for verifying
certificates, it will useful for administrators to attempt to certificates, it will be useful for administrators to attempt to
minimize the length of these authorization chains. minimize the length of these authorization chains.
Where a Router Advertisement is sent by a router, it SHOULD contain Where a Router Advertisement is sent by a router, it SHOULD contain
sufficient information to prove that the router is on the same link sufficient information to prove that the router is on the same link
as previously seen advertisers, or is indeed the same router. This as previously seen advertisers, or is indeed the same router. This
may prevent expensive checks by hosts which will not need to may prevent expensive checks by hosts which will not need to
immediately test the authenticity of the router through signature immediately test the authenticity of the router through signature
verification, or additional transmissions. verification, or additional transmissions. As described in section
Section 3.2, advertising common prefixes achieves this goal.
As described in section Section 3.2, advertising common prefixes
achieves this goal.
Hosts which wish to have secured exchanges with neighbours and on- Hosts which wish to have secured exchanges with neighbours and on-
link routers may use Secured Neighbour Discovery (SEND) [4]. SEND link routers may use Secured Neighbour Discovery (SEND) [4]. SEND
provides authenticity as well as response matching, using nonces provides authenticity as well as response matching, using nonces
copied from solicitations into advertisements. copied from solicitations into advertisements.
Routers supporting DNA SHOULD provide secured router discovery
services using SEND [4].
5. References 5. References
5.1 Normative References 5.1 Normative References
[1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery [1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998. for IP Version 6 (IPv6)", RFC 2461, December 1998.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] 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 14, line 29 skipping to change at page 14, line 31
Centre for Telecommunications and Information Engineering Centre for Telecommunications and Information Engineering
Department of Electrical adn Computer Systems Engineering Department of Electrical adn Computer Systems Engineering
Monash University Monash University
Clayton, Victoria 3800 Clayton, Victoria 3800
Australia Australia
Phone: +61 3 9905 4655 Phone: +61 3 9905 4655
Email: greg.daley@eng.monash.edu.au Email: greg.daley@eng.monash.edu.au
Nicolas Montavont Nicolas Montavont
LSIIT - Univerity Louis Pasteur GET - ENST Bretagne
Pole API, bureau C444 Departement RSM
Boulevard Sebastien Brant 2, rue de la chataigneraie
Illkirch 67400 Cesson-Sevigne 35576
FRANCE FRANCE
Phone: (33) 3 90 24 45 87 Phone: (33) 2 99 12 70 23
Email: montavont@dpt-info.u-strasbg.fr Email: nicolas.montavont@enst-bretagne.fr
URI: http://www-r2.u-strasbg.fr/~montavont/ URI: http://www.rennes.enst-bretagne.fr/~montavont/
Appendix A. Summary of Recommendations Appendix A. Summary of Recommendations
It should be noted that many already deployed routers will not It should be noted that many already deployed routers will not
support these recommendations, and that hosts SHOULD NOT rely on support these recommendations, and that hosts SHOULD NOT rely on
their being in place, unless they have particular reason to do so. their being in place, unless they have particular reason to do so.
Where many unicast responses are scheduled awaiting transmission, Where many unicast responses are scheduled awaiting transmission,
Routers MAY consider aggregating them into a single multicast Routers MAY consider aggregating them into a single multicast
response if a multicast advertisement may be sent before the response if a multicast advertisement may be sent before the
skipping to change at page 19, line 41 skipping to change at page 19, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 27 change blocks. 
53 lines changed or deleted 55 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/