DHCP: Dual-Stack Issues draft-ietf-dhc-dual-stack-01 - PowerPoint PPT Presentation

Loading...

PPT – DHCP: Dual-Stack Issues draft-ietf-dhc-dual-stack-01 PowerPoint presentation | free to download - id: 1c46d3-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

DHCP: Dual-Stack Issues draft-ietf-dhc-dual-stack-01

Description:

dhc WG, IETF 60, San Diego, August 2, 2004. The crux. Nodes in a dual-stack environment may require IPv4 and IPv6 configuration ... – PowerPoint PPT presentation

Number of Views:18
Avg rating:3.0/5.0
Slides: 18
Provided by: timc168
Learn more at: http://users.ecs.soton.ac.uk
Category:
Tags: dhcp | crux | dhc | draft | dual | ietf | issues | stack

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: DHCP: Dual-Stack Issues draft-ietf-dhc-dual-stack-01


1
DHCP Dual-Stack Issuesdraft-ietf-dhc-dual-stack-
01
  • Tim Chown
  • tjc_at_ecs.soton.ac.uk
  • dhc WG, IETF 60, San Diego,
  • August 2, 2004

2
The crux
  • Nodes in a dual-stack environment may require
    IPv4 and IPv6 configuration (addresses and/or
    options).
  • Should we advocate separate DHCPv4 and DHCPv6, or
    add options to DHCPv6 to handle serving DHCPv4
    information?
  • If we choose to have separate servers, how do we
    ensure the multiple sources of configuration
    information are handled by the clients?

3
DHCP servers
  • DHCPv4 (RFC2131)
  • DHCP for IPv4
  • DHCPv6 (RFC3315)
  • For IPv6 nodes using full stateful
    autoconfiguration for address and other
    configuration options
  • Stateless DHCPv6 (RFC3736)
  • For IPv6 nodes using IPv6 stateless address
    autoconfiguration (RFC2462), only using DHCP for
    configuration options (DNS, etc)

4
Configuration information
  • For example
  • IPv4 address
  • IPv6 address
  • DNS server
  • NTP server
  • NIS server
  • DNS search path
  • May receive IPv4 and/or IPv6 addresses for
    configuration options

5
Issue 1 multiple responses
  • How to handle multiple responses?
  • Use most recent data?
  • Prefer DHCPv6 served data or option addresses?
  • Round robin?
  • In some cases this may not be an issue, e.g. two
    different DNS servers should give consistent
    responses to DNS queries.
  • There may be other sources of configuration data,
    e.g. NIS, manually configured files, etc.

6
Issue 2 administration
  • It may be the case that DHCPv4 and DHCPv6 servers
    are maintained by different administrative
    entities
  • This can be argued to be a multihoming issue?

7
Issue 3 multiple interfaces
  • IPv4 and/or IPv6 may be run on different node
    interfaces
  • So are the received configuration data and
    settings per interface or per node?
  • DHCPv6 has the DHCP Unique Identifier (DUID)
    concept to supercede MAC address, DHCP for IPv4
    is introducing this concept
  • draft-ietf-dhc-3315id-for-v4-02

8
Issue 4 DNS load balancing
  • The DHCP server returns different DNS data to
    different nodes to load balance between multiple
    local resolvers
  • May be problematic if trying to balance with
    DHCPv4 and DHPCv6 servers both used
  • Could apply to other services, e.g. NTP

9
Issue 5 DNS search path
  • The search path may vary for administrative
    reasons
  • For example, new IPv6 services may be offered for
    foo.com under .ipv6.foo.com

10
Issue 6 Protocol startup
  • (This has been added in -01 draft)
  • What happens if the IPv6 interface (transport) is
    started after DHCPv4 was used to configure the
    client?
  • Should that data be discarded, or merged with any
    subsequent DHCPv6 response
  • Is the timing issue important?

11
Issue 7 DHCP option variations
  • Some DHCPv4 options arent present in DHCPv6
  • IP version limitations exist, e.g. only IPv6
    servers may be in an IPv6 NTP option
  • DHCP and DHCPv6 option numbers may be different
  • Some sites may use IPv4-mapped addresses in
    DHCPv6-based options - is this a bad thing?
  • Should DHCPv6 options exist that can carry IPv4
    and IPv6 addresses?

12
Two solutions
  • Run separate DHCP and DHCPv6 servers
  • Run a single DHCPv6 server, and add capability to
    serve IPv4 addresses and options
  • Can we agree on a preferred approach?

13
Separate servers (1)
  • Servers may or may not be on same node
  • Server configuration data could be generated from
    a single database
  • Implies client has heuristics to handle (merge)
    multiple server responses
  • In some cases inconsistencies wont matter
  • Need a per-host preference method, e.g. Prefer
    DHCPv6
  • Need a method to merge list responses, e.g.
    alternate, DHCPv6 first
  • How to handle merging names and addresses?

14
Separate servers (2)
  • If we take this approach, we need to identify
    situations where differences in DHCPv4 and DHCPv6
    responses may impact node behaviour
  • We must place some faith in the site
    administrator to configure the DHCPv4 and DHCPv6
    servers consistently
  • But we need to be confident that functionality is
    retained (e.g. DNS load balancing)
  • If we take this path, we need to complete this
    task

15
Single DHCPv6 server (1)
  • Have just one (DHCPv6) server
  • Modify DHCPv6 to return IPv4 information (over
    IPv6 transport/lookup)
  • Possibility is hinted at in RFC3315
  • Single server and transport leads to simplicity
    and predictability, and less failure modes
  • Do we want dual-stack nodes to use separate
    DHCPv4 and DHCPv6 servers for the next 10 or 20
    years?

16
Single DHCPv6 server (2)
  • A number of potential problems/issues arise
  • IPv4-only nodes cant use DHCPv4 any more if you
    do run DHCPv4 for these nodes, you then still
    have duplication of information
  • An IPv6-only node cant use DHCPv4 responses
  • What if a responding DHCPv6 server isnt able or
    configured to serve IPv4 information?
  • If IPv4 addresses are allocated from DHCPv4 and
    DHPCv6 servers, more stress is placed on valuable
    IPv4 address space
  • The DHCPv6 specification will become more complex
    and bloated to enable this capability

17
Way forward?
  • Can we agree one path?
  • The list seems to lean towards separate servers,
    but its not clear the consensus is strong?
  • If we adopt the two server approach, we need to
    do more analysis of inconsistency impact, methods
    to specify preferences, etc.
  • There is one early implementation of preferences
  • Should we abstract the multihoming/dna issues?
  • Need to answer these two and edit to -02 version
    before any WGLC could be considered
About PowerShow.com