draft-ietf-v6ops-conditional-ras-07.txt   draft-ietf-v6ops-conditional-ras-08.txt 
IPv6 Operations J. Linkova IPv6 Operations J. Linkova
Internet-Draft Google Internet-Draft Google
Intended status: Informational M. Stucchi Intended status: Informational M. Stucchi
Expires: February 11, 2019 RIPE NCC Expires: February 22, 2019 RIPE NCC
August 10, 2018 August 21, 2018
Using Conditional Router Advertisements for Enterprise Multihoming Using Conditional Router Advertisements for Enterprise Multihoming
draft-ietf-v6ops-conditional-ras-07 draft-ietf-v6ops-conditional-ras-08
Abstract Abstract
This document discusses the most common scenarios of connecting an This document discusses the most common scenarios of connecting an
enterprise network to multiple ISPs using an address space assigned enterprise network to multiple ISPs using an address space assigned
by an ISP and how the approach proposed in the "ietf-rtgwg- by an ISP and how the approach proposed in the "ietf-rtgwg-
enterprise-pa-multihoming" draft could be applied in those scenarios. enterprise-pa-multihoming" draft could be applied in those scenarios.
The problem of enterprise multihoming without address translation of The problem of enterprise multihoming without address translation of
any form has not been solved yet as it requires both the network to any form has not been solved yet as it requires both the network to
select the correct egress ISP based on the packet source address and select the correct egress ISP based on the packet source address and
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on February 11, 2019. This Internet-Draft will expire on February 22, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 6, line 40 skipping to change at page 6, line 40
o making a previously unused (deprecated) prefix usable again (by o making a previously unused (deprecated) prefix usable again (by
sending an RA containing a PIO with non-zero preferred lifetime) sending an RA containing a PIO with non-zero preferred lifetime)
to indicate to hosts that addresses from that prefix can be used to indicate to hosts that addresses from that prefix can be used
again. again.
It should be notes that only preferred lifetime for the affected It should be notes that only preferred lifetime for the affected
prefix needs to be changed. As the goal is to influence the source prefix needs to be changed. As the goal is to influence the source
address selection algoorithm on hosts, not preventing them from address selection algoorithm on hosts, not preventing them from
forming addresses from a specific prefix, the valid lifetime should forming addresses from a specific prefix, the valid lifetime should
not be changed. Actually it would not even be possible as not be changed. Actually it would not even be possible for
unauthenticated RAs (which is the most common deployment scenario) as
Section 5.5.3 of [RFC4862] prevents hosts from setting valid lifetime Section 5.5.3 of [RFC4862] prevents hosts from setting valid lifetime
for addresses to zero. for addresses to zero unless RAs are authenticated.
To provide the desired functionality, first-hop routers are required To provide the desired functionality, first-hop routers are required
to to
o send RA triggered by defined event policies in response to uplink o send RA triggered by defined event policies in response to uplink
status change event; and status change event; and
o while sending periodic or solicted RAs, set the value in the given o while sending periodic or solicted RAs, set the value in the given
RA field (e.g. PIO preferred lifetime) based on the uplink RA field (e.g. PIO preferred lifetime) based on the uplink
status. status.
 End of changes. 5 change blocks. 
6 lines changed or deleted 7 lines changed or added

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