ETSI TS 102 514 V2.1.1 (2008-02)
Methods for Testing and Specification (MTS); Internet Protocol Testing (IPT): IPv6 Core Protocol; Requirements Catalogue
Methods for Testing and Specification (MTS); Internet Protocol Testing (IPT): IPv6 Core Protocol; Requirements Catalogue
RTS/MTS-IPT-003[2]-IPv6-CrRqCa
General Information
Standards Content (Sample)
ETSI TS 102 514 V2.1.1 (2008-02)
Technical Specification
Methods for Testing and Specification (MTS);
Internet Protocol Testing (IPT): IPv6 Core Protocol;
Requirements Catalogue
---------------------- Page: 1 ----------------------
2 ETSI TS 102 514 V2.1.1 (2008-02)
Reference
RTS/MTS-IPT-003[2]-IPv6-CrRqCa
Keywords
IP, IPv6, testing
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 2008.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
ETSI
---------------------- Page: 2 ----------------------
3 ETSI TS 102 514 V2.1.1 (2008-02)
Contents
Intellectual Property Rights.4
Foreword.4
1 Scope.5
2 References.5
2.1 Normative references.5
3 Abbreviations.6
4 Requirements Catalogue.6
4.1 Requirements extracted from TS 123 060.6
4.2 Requirements extracted from TS 123 221.8
4.3 Requirements extracted from TS 129 061.8
4.4 Requirements extracted from RFC 1981.25
4.5 Requirements extracted from RFC 2460.29
4.6 Requirements extracted from RFC 2461.72
4.7 Requirements extracted from RFC 2462.261
4.8 Requirements extracted from RFC 2463.283
4.9 Requirements extracted from RFC 2464.314
4.10 Requirements extracted from RFC 2675.318
4.11 Requirements extracted from RFC 3513.326
Annex A (informative): Duplicated requirements.355
Annex B (informative): Bibliography.357
History .358
ETSI
---------------------- Page: 3 ----------------------
4 ETSI TS 102 514 V2.1.1 (2008-02)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Methods for Testing and
Specification (MTS).
ETSI
---------------------- Page: 4 ----------------------
5 ETSI TS 102 514 V2.1.1 (2008-02)
1 Scope
The purpose of the present document is to provide a catalogue of requirements extracted from the core IPv6 RFCs (see
references in clause 2) and from ETSI Specifications. The catalogue follows the guidelines defined by the MTS IPv6
Testing: Methodology and Framework (see TS 102 351 in bibliography).
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• Non-specific reference may be made only to a complete document or a part thereof and only in the following
cases:
- if it is accepted that it will be possible to use all future changes of the referenced document for the
purposes of the referring document;
- for informative references.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably,
the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the
reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the
method of access to the referenced document and the full network address, with the same punctuation and use of upper
case and lower case letters.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are indispensable for the application of the present document. For dated
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document
(including any amendments) applies.
[1] IETF RFC 1122: "Requirements for Internet Hosts - Communication Layers".
[2] IETF RFC 1981: "Path MTU Discovery for IP version 6".
[3] IETF RFC 2373: "IP Version 6 Addressing Architecture".
[4] IETF RFC 2402: "IP Authentication Header".
[5] IETF RFC 2460: "Internet Protocol, Version 6 (IPv6) Specification".
[6] IETF RFC 2461: "Neighbor Discovery for IP Version 6 (IPv6)".
[7] IETF RFC 2462: "IPv6 Stateless Address Autoconfiguration".
[8] IETF RFC 2463: "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6) Specification".
[9] IETF RFC 2464: "Transmission of IPv6 Packets over Ethernet Networks".
[10] IETF RFC 2675: "IPv6 Jumbograms".
[11] IETF RFC 3513: "Internet Protocol Version 6 (IPv6) Addressing Architecture".
ETSI
---------------------- Page: 5 ----------------------
6 ETSI TS 102 514 V2.1.1 (2008-02)
[12] ETSI TS 123 060: "Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); General Packet Radio Service (GPRS); Service
description; Stage 2 (3GPP TS 23.060)".
[13] ETSI TS 123 221: "Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); Architectural requirements (3GPP TS 23.221)".
[14] ETSI TS 123 228: "Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); IP Multimedia Subsystem (IMS); Stage 2
(3GPP TS 23.228)".
[15] ETSI TS 129 061: "Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); Interworking between the Public Land Mobile Network
(PLMN) supporting packet based services and Packet Data Networks (PDN) (3GPP TS 29.061)".
3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ICMP Internet Control Message Protocol
IE Information Element
MTU Maximum Transmission Unit
ND Neighbor Discovery
PDP Packet Data Protocol
PMTU Path MTU
TCP Transfer Control Protocol
UDP User Datagram Protocol
4 Requirements Catalogue
The requirements below have been extracted from IETF RFCs 1981 [2], 2460 [5], 2461 [6], 2462 [7], 2463 [8],
2464 [9], 2675 [10], 3513[11]) and ETSI specifications TS 123 060 [12], TS 123 221 [13], TS 123 228 [14],
TS 129 061 [15]).
4.1 Requirements extracted from TS 123 060
RQ_000_7003 Configure Address
TS 123 060 9.2.1.1 MANDATORY
Applies to: Host
Context:
An IPv6 Mobile Station is performing either stateless or stateful address autoconfiguration
Requirement:
An IPv6 Mobile Station SHALL use the interface identifier provided by the Gateway GPRS Support
Node to configure its link-local address
Specification Text:
To ensure that the link-local address generated by the MS does not collide with the link-local
address of the GGSN, the GGSN shall provide an interface identifier (see RFC 2462 [69]) to the
MS and the MS shall use this interface identifier to configure its link-local address. This is
applicable for both stateful and stateless IPv6 address autoconfiguration. In case of stateless
address autoconfiguration however, the MS can choose any interface identifier to generate
addresses other than link-local, without involving the network. In particular, the SGSN and the
GGSN are not updated with the actual address used by the MS, as the prefix alone identifies the
PDP context.
ETSI
---------------------- Page: 6 ----------------------
7 ETSI TS 102 514 V2.1.1 (2008-02)
RQ_000_7004 Detect Duplicate Address (DAD)
TS 123 060 9.2.1.1 OPTIONAL
Applies to: Host
Context:
An IPv6 Mobile Station is performing stateless address autoconfiguration using a prefix
advertised by a Gateway BPRS Support Node in a PDP context.
Requirement:
The IPv6 Mobile Station MAY omit duplicate address detection.
Specification Text:
Because any prefix that the GGSN advertises in a PDP context is unique within the scope of the
prefix (i.e. site-local or global), there is no need for the MS to perform Duplicate Address
Detection for this IPv6 address. Therefore, the GGSN shall silently discard Neighbor
Solicitation messages that the MS may send to perform Duplicate Address Detection. It is
possible for the MS to perform Neighbor Unreachability Detection towards the GGSN, as defined
in RFC 2461[71]; therefore if the GGSN receives a Neighbor Solicitation as part of this
procedure, the GGSN shall provide a Neighbor Advertisement as described in RFC 2461.
RQ_000_7005 Detect Duplicate Address (DAD)
TS 123 060 9.2.1.1 MANDATORY
Applies to: Router
Context:
An IPv6 Mobile Station is performing stateless address autoconfiguration using a prefix
advertised by a Gateway BPRS Support Node in a PDP context.
Requirement:
The IPv6 Gateway GPRS Support NODE SHALL silently discard any Neighbor Solicitation messages
sent by the IPv6 Mobile Station.
Specification Text:
Because any prefix that the GGSN advertises in a PDP context is unique within the scope of the
prefix (i.e. site-local or global), there is no need for the MS to perform Duplicate Address
Detection for this IPv6 address. Therefore, the GGSN shall silently discard Neighbor
Solicitation messages that the MS may send to perform Duplicate Address Detection. .
RQ_000_7006 Stateless Autoconfiguration
TS 123 060 9.2.1.1 MANDATORY
Applies to: Router
Context:
An IPv6 Mobile Station has sent an "Activate PDP Context Request" to its Serving GPRS Support
Node
Requirement:
The IPv6 Gateway GPRS Support Node SHALL NOT advertise the same prefix on more than one PDP
context on a given APN or set of APNs, within the same addressing scope.
Specification Text:
The GGSN sends a Router Advertisement message. The Router Advertisement messages shall contain
the same prefix as the one provided in step 2. A given prefix shall not be advertised on more
than one PDP context on a given APN, or set of APNs, within the same addressing scope. The GGSN
shall be configured to advertise only one prefix per PDP context
After the MS has received the Router Advertisement message, it constructs its full IPv6 address
by concatenating the interface identifier received in step 3, or a locally generated interface
identifier, and the prefix received in the Router Advertisement. If the Router Advertisement
contains more than one prefix option, the MS shall only consider the first one and silently
discard the others.
RQ_000_7007 Stateless Autoconfiguration
TS 123 060 9.2.1.1 MANDATORY
Applies to: Host
Context:
An IPv6 Mobile Station receives a Router Advertisement message which contains more than one
prefix.
Requirement:
The IPv6 Mobile Station SHALL use the first prefix and silently discard the others.
Specification Text:
The GGSN sends a Router Advertisement message. The Router Advertisement messages shall contain
the same prefix as the one provided in step 2. A given prefix shall not be advertised on more
than one PDP context on a given APN, or set of APNs, within the same addressing scope. The GGSN
shall be configured to advertise only one prefix per PDP context
ETSI
---------------------- Page: 7 ----------------------
8 ETSI TS 102 514 V2.1.1 (2008-02)
After the MS has received the Router Advertisement message, it constructs its full IPv6 address
by concatenating the interface identifier received in step 3, or a locally generated interface
identifier, and the prefix received in the Router Advertisement. If the Router Advertisement
contains more than one prefix option, the MS shall only consider the first one and silently
discard the others.
RQ_000_7009 Startup Router Advertisement Behavior
TS 123 060 9.2.1.1 MANDATORY
Applies to: Router
Context:
Requirement:
An IPv6 Gateway GPRS Support Node shall automatically and periodically send Router
Advertisement messages towards the Mobile Station after a PDP context of type IPv6 is activated
Specification Text:
IPv6 stateful address autoconfiguration uses the standard External PDN Address Allocation
procedure, as described in TS 29.061. The GGSN informs the MS that it shall perform stateful
address autoconfiguration by means of the Router Advertisements, as defined in RFC 2461. For
this purpose, the GGSN shall automatically and periodically send Router Advertisement messages
towards the MS after a PDP context of type IPv6 is activated. The use of stateless or stateful
address autoconfiguration is configured per APN.
4.2 Requirements extracted from TS 123 221
RQ_000_7010 3GPP UE supports IPv6
TS 123 221 5.6 MANDATORY
Applies to: Host
Context:
Requirement:
A 3GPP User Equipment supporting IPv6 SHALL comply with the Basic IP group of specifications as
defined in RFC3316.
Specification Text:
The set of IPv6 functionality a 3GPP UE will require is dependent on the services (IMS, Packet
Streaming etc.) it will use.
As a minimum, a 3GPP UE shall comply with the Basic IP group of specifications as defined in
RFC3316. This IPv6 functionality is sufficient to provide compatibility towards IPv6 entities
external to 3GPP.
A 3GPP UE shall follow the recommendations for the IP Security set of functions in RFC3316
when a specific service requires such functions.
According to the procedures defined in TS 23.060, when a UE is assigned an IPv6 prefix, it can
change the global IPv6 address it is currently using via the mechanism defined in RFC 3041, or
similar means, without updating the PS domain. Any application that requires full IP address
knowledge shall provide a mechanism to get the latest IPv6 address when the IPv6 address in the
UE has been changed. An example of such means is defined in TS 23.228.
Note: RFC3316 does not make any recommendations on preferred transition and interoperability
mechanisms between IPv4 and IPv6.
4.3 Requirements extracted from TS 129 061
RQ_000_7000 Configure Address
TS 129 061 11.2.1.3 MANDATORY
Applies to: Host
Context:
An IPv6 Mobile Station which is capable of both stateless and stateful autoconfiguration.
Requirement:
The IPv6 Mobile Station SHALL use stateless autoconfiguration to configure the address and
stateful autoconfiguration to configure additional parameters only.
Specification Text:
Stateful and Stateless Autoconfiguration may also co-exist. In that case, the MS shall use
Stateless to configure the address and Stateful to configure additional parameters only. The MS
shall not use Stateless and Stateful Address Autoconfiguration simultaneously since GPRS only
supports one prefix per PDP.
ETSI
---------------------- Page: 8 ----------------------
9 ETSI TS 102 514 V2.1.1 (2008-02)
RQ_000_7001 Configure Address
TS 129 061 11.2.1.3 MANDATORY
Applies to: Host
Context:
Requirement:
An IPv6 Mobile Station SHALL NOT use both stateless and stateful autoconfiguration
simultaneously.
Specification Text:
Stateful and Stateless Autoconfiguration may also co-exist. In that case, the MS shall use
Stateless to configure the address and Stateful to configure additional parameters only. The MS
shall not use Stateless and Stateful Address Autoconfiguration simultaneously since GPRS only
supports one prefix per PDP Context
RQ_000_7002 Configure Address
TS 129 061 11.2.1.3 MANDATORY
Applies to: Host
Context:
Requirement:
An IPv6 Mobile Station SHALL support stateless address autoconfiguration.
Specification Text:
For MS, IPv6 Stateless Address Autoconfiguration is mandatory, and IPv6 Stateful Address
Autoconfiguration is optional.
RQ_000_7008 Startup Router Advertisement Behavior
TS 129 061 11.2.1.3.2 OPTIONAL
Applies to: Router
Context:
Requirement:
AN IPv6 Gateway GPRS Support Node MAY omit the randomisation of the period between sending
Router Advertisements.
Specification Text:
The handling of Router Advertisements shall be consistent with what is specified in RFC 2461
[44]. For the MS-GGSN link however, some specific handling shall apply. The randomisation part
to determine when Router Advertisements shall be sent may be omitted since the GGSN is the only
router on the link. Furthermore, some 3GPP specific protocol constants and default values shall
apply (see subclause "IPv6 Router Configuration Variables in the GGSN"). These relate to the
periodicity of the Router Advertisements initially and during continued operation. The
motivation for this is to have a faster user-plane set-up even in bad radio conditions and to
minimize MS power consumption during long continued operation.
RQ_000_7011 Configure Address
TS 129 061 11.2.1.3 OPTIONAL
Applies to: Host
Context:
Requirement:
An IPv6 Mobile Station MAY support stateful address autoconfiguration.
Specification Text:
For MS, IPv6 Stateless Address Autoconfiguration is mandatory, and IPv6 Stateful Address
Autoconfiguration is optional.
ETSI
---------------------- Page: 9 ----------------------
10 ETSI TS 102 514 V2.1.1 (2008-02)
RQ_000_7012 MaxRtrAdvInterval
TS 129 061 11.2.1.3.4 MANDATORY
Applies to: Router
Context:
Requirement:
The default value of the configurable timer, MaxRtrAdvInterval in a 3GPP IPv6 router shall be
21,600s (6 hours).
Specification Text:
For IPv6 Stateless and Stateful Address Autoconfiguration to work properly the GGSN shall
behave as an IPv6 router towards the MS. In this respect the GGSN shall be consistent with the
RFCs specifying this process (for example RFC 2462 and RFC 2461), unless stated otherwise in
this or other 3GPP specifications.
RFC 2461 specifies a set of conceptual router configuration variables. Some of these variables
require particular attention in GPRS in order to preserve radio resources and MS power
consumption while still allowing for appropriate robustness and fast user-plane set-up time
even in bad radio conditions, or simply because they have a particular meaning in GPRS. These
particular variables are listed below with appropriate (default) values and shall be
configurable per APN. The values specified hereafter are specific to GPRS and supersede those
specified in RFC 2461.
MaxRtrAdvInterval
Shall have a default value of 21 600 s (6 h).
MinRtrAdvInterval
Shall have a default value of 0,75 × MaxRtrAdvInterval i.e.16 200 s (4,5 h).
AdvValidLifetime
Shall have a value giving Prefixes infinite lifetime, i.e. 0xFFFFFFFF.
The assigned prefix remains Preferred until PDP Context Deactivation.
AdvPreferredLifetime
Shall have a value giving Prefixes infinite lifetime, i.e. 0xFFFFFFFF.
The assigned prefix remains Preferred until PDP Context Deactivation.
RFC 2461 also specifies a number of protocol constants. The following shall have specific
values for GPRS:
MAX_INITIAL_RTR_ADVERT_INTERVAL
This constant may be a variable within GPRS. It may have a value
that gradually increases (exponentially or by some other means) with
the number of initial Router Advertisements sent. This will enable a
fast set-up of the MS-GGSN link in most cases, while still allowing
the MS to receive a Router Advertisement within the initial phase,
even in case of bad radio conditions or slow response time, without
having to send a large number of initial Router Advertisements.
MAX_INITIAL_RTR_ADVERTISEMENTS
This is the number of Router Advertisements sent during the initial
phase after the MS-GGSN link has been established. The value of
this constant shall be chosen carefully, and in conjunction with
MAX_INITIAL_RTR_ADVERT_INTERVAL, so as to not overload the radio
interface while still allowing the MS to complete its configuration
in a reasonable delay. For instance, the default value could be
chosen so that initial Router Advertisements are sent for at least 30 s.
After the initial phase, the periodicity is controlled by the
MaxRtrAdvInterval and the MinRtrAdvInterval constants.
ETSI
---------------------- Page: 10 ----------------------
11 ETSI TS 102 514 V2.1.1 (2008-02)
RQ_000_7013 MinRtrAdvInterval
TS 129 061 11.2.1.3.4 MANDATORY
Applies to: Router
Context:
Requirement:
The default value of the configurable timer, MinRtrAdvInterval in a 3GPP IPv6 router SHALL be
0.75 x MaxRtrAdvInterval (4,5 hours).
Specification Text:
For IPv6 Stateless and Stateful Address Autoconfiguration to work properly the GGSN shall
behave as an IPv6 router towards the MS. In this respect the GGSN shall be consistent with the
RFCs specifying this process (for example RFC 2462 and RFC 2461), unless stated otherwise in
this or other 3GPP specifications.
RFC 2461 specifies a set of conceptual router configuration variables. Some of these variables
require particular attention in GPRS in order to preserve radio resources and MS power
consumption while still allowing for appropriate robustness and fast user-plane set-up time
even in bad radio conditions, or simply because they have a particular meaning in GPRS. These
particular variables are listed below with appropriate (default) values and shall be
configurable per APN. The values specified hereafter are specific to GPRS and supersede those
specified in RFC 2461.
MaxRtrAdvInterval
Shall have a default value of 21 600 s (6 h).
MinRtrAdvInterval
Shall have a default value of 0,75 × MaxRtrAdvInterval i.e.16 200 s (4,5 h).
AdvValidLifetime
Shall have a value giving Prefixes infinite lifetime, i.e. 0xFFFFFFFF.
The assigned prefix remains Preferred until PDP Context Deactivation.
AdvPreferredLifetime
Shall have a value giving Prefixes infinite lifetime, i.e. 0xFFFFFFFF.
The assigned prefix remains Preferred until PDP Context Deactivation.
RFC 2461 also specifies a number of protocol constants. The following shall have specific
values for GPRS:
MAX_INITIAL_RTR_ADVERT_INTERVAL
This constant may be a variable within GPRS. It may have a value
that gradually increases (exponentially or by some other means) with
the number of initial Router Advertisements sent. This will enable a
fast set-up of the MS-GGSN link in most cases, while still allowing
the MS to receive a Router Advertisement within the initial phase,
even in case of bad radio conditions or slow response time, without
having to send a large number of initial Router Advertisements.
MAX_INITIAL_RTR_ADVERTISEMENTS
This is the number of Router Advertisements sent during the initial
phase after the MS-GGSN link has been established. The value of
this constant shall be chosen carefully, and in conjunction with
MAX_INITIAL_RTR_ADVERT_INTERVAL, so as to not overload the radio
interface while still allowing the MS to complete its configuration
in a reasonable delay. For instance, the default value could be
chosen so that initial Router Advertisements are sent for at least 30 s.
After the initial phase, the periodicity is controlled by the
MaxRtrAdvInterval and the MinRtrAdvInterval constants.
ETSI
---------------------- Page: 11 ----------------------
12 ETSI TS 102 514 V2.1.1 (2008-02)
RQ_000_7014 RA Prefix Option
TS 129 061 11.2.1.3.4 MANDATORY
Applies to: Router
Context:
Requirement:
The default value of the configurable timer, AdvValidLifetime in a 3GPP IPv6 router SHALL be
0xFFFFFFFFH
Specification Text:
For IPv6 Stateless and Stateful Address Autoconfiguration to work properly the GGSN shall
behave as an IPv6 router towards the MS. In this respect the GGSN shall be consistent with the
RFCs specifying this process (for example RFC 2462 and RFC 2461), unless stated otherwise in
this or other 3GPP specifications.
RFC 2461 specifies a set of conceptual router configuration variables. Some of these variables
require particular attention in GPRS in order to preserve radio resources and MS power
consumption while still allowing for appropriate robustness and fast user-plane set-up time
even in bad radio conditions, or simply because they have a particular meaning in GPRS. These
particular variables are listed below with appropriate (default) values and shall be
configurable per APN. The values specified hereafter are specific to GPRS and supersede those
specified in RFC 2461.
MaxRtrAdvInterval
Shall have a default value of 21 600 s (6 h).
MinRtrAdvInterval
Shall have a default value of 0,75 × MaxRtrAdvInterval i.e.16 200 s (4,5 h).
AdvValidLifetime
Shall have a value giving Prefixes infinite lifetime, i.e. 0xFFFFFFFF.
The assigned prefix remains Preferred until PDP Context Deactivation.
AdvPreferredLifetime
Shall have a value giving Prefixes infinite lifetime, i.e. 0xFFFFFFFF.
The assigned prefix remains Preferred until PDP Context Deactivation.
RFC 2461 also specifies a number of protocol constants. The following shall have specific
values for GPRS:
MAX_INITIAL_RTR_ADVERT_INTERVAL
This constant may be a variable within GPRS. It may have a value
that gradually increases (exponentially or by some other means) with
the number of initial Router Advertisements sent. This will enable a
fast set-up of the MS-GGSN link in most cases, while still allowing
the MS to receive a Router A
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.