Scribd
Upload
14 views6 pages

Slides 106 DHC dhcpv6 Prefix Delegating Relay 00

Uploaded by

risket01
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
14 views6 pages

Slides 106 DHC dhcpv6 Prefix Delegating Relay 00

Uploaded by

risket01
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 6

DHCPv6 Prefix Delegating Relay

draft-fkhp-dhc-dhcpv6-pd-relay-requirements-02
I. Farrer, N. Kottapalli, M. Hunek, R. Patterson

IETF106 Singapore

1
Introduction
• Operational experience of mainstream
commercial relay/router implementations have
shown a number of problems when the
delegating router/relay function is separated
from the DHCPv6 server

DHCPv6 PD client / DHCPv6 Server


Requesting router L3 Edge router Intermediate L3
(e.g. HGW) DHCPv6 relay node(s)
(Delegating relay)

• The draft uses the term ‘delegating relay’ to


describe this device 2
What Problems have we seen?
• Messages not being forwarded by the relay
– Relay decides if the message will be forwarded or not
• Relay generating messages/errors on behalf of server
• Loss of PD state on reboot
– The relay loses PD state and client traffic can’t be
forwarded
• Multiple PD leases by a single client
– Relay will only create a single prefix binding per-DUID
• Dropping messages with duplicate MAC or DUID
received on different interfaces
3
What has RFC8415 got to say about it?
• RFC8415 is sketchy on how this is meant to work
(section 19.1.3):
A relay agent forwards messages containing prefix delegation
options in the same way as it would relay addresses (i.e., per
Sections 19.1.1 and 19.1.2).
If a server communicates with a client through a relay agent
about delegated prefixes, the server may need a protocol or
other out-of-band communication to configure routing
information for delegated prefixes on any router through which
the client may forward traffic.
• This is true, but incomplete – the relay needs to
implement a state machine synchronized with the server
and client
• The lack of existing specification makes it difficult for to
get implementations with
• This draft describes problems that and defines a set of
requirements
4
Requirements
• Follows the RFC7084 approach of an Informational
document with RFC2119 requirements language
(changed in -v02)
• 4 categories of requirements
– General
• Message forwarding, multiple prefixes, lease/timer maintenance
– Routing
• Only deals with routing between relay and client, prefix re-
distribution is not covered
– Service continuity
• PD persistent storage, lease query and client link failures
– Operational
• PD state and maintenance

5
Next Steps…
• Some comments have been received
– v02 incorporates these
• Any additional reviews or feedback welcome!
– Especially interested in any additional problems
that have been observed in operator deployments
– Suggestions for additional requirements

• Call for WG adoption?

You might also like