IETF-83 6renum WG Minutes

Tuesday 27th March 2012

Chairs:
Tim Chown (tjc@ecs.soton.ac.uk)
Wes George (wesley.george@twcable.com)

Minute taker: Steven Blake

Welcome and administrivia, agenda bashing
http://www.ietf.org/proceedings/83/slides/slides-83-6renum-0.pptx
- no comments

Homenet update; "flash renumbering" - Tim Chown
- Discuss fact that home networks may be renumbered more frequently than
  originally foreseen.
- Will discuss with ADs whether some of that work will be addressed in 
  this WG in the future.

Enterprise Scenarios
draft-ietf-6renum-enterprise-00 - Sheng Jiang
http://www.ietf.org/proceedings/83/slides/slides-83-6renum-1.ppt

- Wes: "In the case of mixed DHCP?"

- Benedict Stockebrand: Let IPv4 die; mixing IPv4 & IPv6 in the context 
  of renumbering, we shouldn't put much effort into addressing it. 

- Wes: but these configurations exist.

- Benedict: better to have separate instances. This is not good practice.

- Lee Howard: are we talking about IPv4 information in DHCPv6 response?

- Sheng: DS-Lite scenario

- Lee: probably want to say something; in scope

- Joel J: we won't advance the state of the art, we should take that notion
  seriously

- Tim C: we are not going to fix these issues. Mention in gap analysis 
  that we are not going to fix this here.

- Wes: in the case of DS, where IPv4 & IPv6 live on same server, 
  still out-of-scope.

- Tim C: re: multicast DNS, proposal in homenet to extend beyond link-local.

- Wes: does this draft refer to SEND?

- Sheng: think we considered SEND.   Security considerations have two levels:
  one with regular ND, discuss normal issues for ND.

- Wes: there are other places where this is discussed, should reference them
  in this draft.

- Sheng: not sure SEND will solve this issue.

- Joel J: SEND RFCs describe the problem. Security considerations need to
  be explicit on the exposure

- Sheng: will add reference

- Tim: part of the process is managing & monitoring the renumbering

- Ilijtch van Beijnum: renumbering nothing more than getting new addresses, 
  forgeting older ones. Could start bogus RA and all hosts would configure 
  new addresses. No protections if DHCP server doesn't renew leases.  Why 
  is security suddenly a big issue.

- Tim: same security considerations apply.   In the general case, agree with
  what you are saying.

- Sheng: nothing new for renumbering.

- Benedict: doing anything like DHCPv6 PD in an enterprise environment is not
  likely. Ok for home nets.  Enterprises have professionals; don't want
  something stupid to happen.  Renumbering is dangerous, especially when using
  fully automatic tools. Would stay away from all mechanisms that take me
  out of control.

- Tim: where does homenet end, and enterprise begin?

- Benedict: important distinction is having people around that know what they
  are doing.

- Philip Matthews: small enterprise (DSL service) "flower shop", treat them
  like a homenet. Large enterprise (static allocation) not going into a
  BRAS, likely a dedicated router port. Would put filters on DHCPv6 PD
  option (must be exactly right).

- Lee: definition of enterprise not based on access method. In our network,
  the way we get routing info for cable customers, CMTS watches PD go past;
  otherwise need to run dynamic routing protocol with customers.

- Tim: can we offer two prefixes simultaneously thru a renumbering event.

- Lee: currently no; depends on DHCP PD server vendor.

- Philip: small == homenet, large often getting different services (L2VPN,
  L3VPN).

- Eric Vyncke: DHCP PD can send another prefix ?

- Tim: which is the new prefix, which is the old?

- Dan York: enterprise have a control factor (staff). Big enterprises don't
  want outside factors driving renumbering.

- Lan ? (Sweden): DNS root zone signed for at least a year.

- Dan: increasing number of domains (~80) signed at the top-level. US govt,
  Sweden, Czech Republic pushing DNSSEC along. Comcast just turned up
  DNSSEC validating resolvers.  Deploy360

- Benedict: seen a lot of networks where DNS FQDN were not considered an option.
  Need bootstrapping.   If packet filtering uses DNSSEC for routing table, and
  can reach the DNS server, broken.   Will have literal addresses in
  configurations.   Can minimize the use, but can't get away from it.

- Tim: starting list of those in the draft.

- Benedict: should continue with that list

- Dan: what are you looking for DNSSEC to do.

- Tim: want to avoid using address literals, want to be able to trust the names

- Dan: in the enterprise domain? Wouldn't you have control?

- Sheng: talking about enterprise

- Dan: not sure about applicability since enterprise has control over its
  DNS entries

- Tim: protect against internal attacker. Example is open campus net

- Joel J: lots of use cases for .local entries that do renumber (e.g., printer,
  Apple TV, etc.). Those cases are worthy of consideration.

- Wes: don't worry about exhaustive list of cases. Use FQDN where it is
  reasonable, list cases where it is not reasonable. Can't come up with
  a complete list of examples for using FQDN.

- Tim: v6ops topic: use link-locals between routers.   Might want to consider
  that.

- Tim re: RA Guard: not sure what the question is?

- ?: existing implementations of RA Guard. If you renumber, need to change
  RA Guard configuration (if filter looks at content, not just who sends it).

- Sheng: yes

- Tim: re: figure: ascii art good, not sure it is important.

- Sheng: some suggested that the figure should be more complicated.

- Tim: constrainted by current RFC format

- Benedict: could have multiple pictures.

- Wes: want more reviews of this draft before last call.


Gap Analysis
draft-ietf-6renum-gap-analysis-01 - Bing Liu
http://www.ietf.org/proceedings/83/slides/slides-83-6renum-2.ppt

- Tim: any experience in room on TSIG

- Benedict: a few years ago, implemented some lab-grade stuff using TSIG
  Questions remain on using public-key crypto with renumbering, computations
  of multiple machines updating entries might melt down server. Might
  want an approach to updating literal addresses.

- Ilijtsch: been running dyn DNS server without security for years. Main
  issue is autoconfiguration. Important to do this, but not specific for
  this WG; don't have a general solution in IPv6 for reverse DNS w/ temporary
  addresses. Should revive bit labels in A6 (but won't happen).

- Lee: in the past, many of these options weren't available, used access
  control before allowing a host on the network, then accepted any updates
  from the host. Good enough approach.

- Tim: good stuff

- Benedict: comment on Ilijtsh's suggestions: one tool to generate the TSIG
  key (shell script), have another script to update forward zone. Should
  be safe. From an enterprise PoV, can be done reasonably well. Tool
  on my home page. Synchronizes forward & reverse entries.

Multicast gaps - Stig Venaas 

- Tim: are you considering Fred Baker model where two prefixes could be
  alive for a period of time, or are you assuming rapid cutover.

- Stig: more complicated for mcast to have two simultaneous prefixes.

- Takebod (sp?): in enterprise don't see MSDP a lot.

- Stig: some cases with MSDP (resilience with multiple RPs), shouldn't be
  a big deal.

- Benedict: from what I consider normal, don't expect to see enterprises
  running mcast to the outside.  Providers can't predict traffic rate,
  which is bad for flat-rate pricing.  Also, mcast uses router memory.
  Use ULAs for mcast rendevous points inside.  Problems you are discussing
  are very special.

- Stig: could also use ULAs for mcast sources.  Might be issues with address
  selection.

- Benedict: not saying that it is going to be easy.

- Tim: interesting observation about using mcast outside site.  Not uncommon
  in university networks.

- Stig: cases where mcast is between two domains.

- Tim: once you have multiple domains, can't use ULAs.

- Benedict: might see this in research network, not in business network.
  Mcast doesn't scale that well, ISPs won't support it.

- Stig: some different opinions on that.   Draft will add text on using
  ULAs.

- Benedict: if draft says these are the options, if none are applicable to
  you, you have a problem.

- Takabod (sp?): need to discuss consequences of renumbering for mcast.
  Source-specific mcast: there are dangers.


Static Addresses Problem
draft-carpenter-6renum-static-problem-02  - Sheng Jiang
http://www.ietf.org/proceedings/83/slides/slides-83-6renum-3.ppt

- Philip Matthews: this draft gets to the heart of the problem. Suggests that
  I can number my loopbacks using ULAs. Could use DHCP or SLAAC for hosts.
  Don't see how to number host-facing router interfaces. Must be global,
  want it to renumber.

- Ilijtsch: use link-local

- Philip: can't ping it to make sure it is alive

- Fred Baker: couple of drafts. RFC 4192 (one global prefix to another one).
  My passive (?) IP draft I wrote.

- Philip: don't think this solves the problem

- Fred: RFC 4192 addresses having more than one prefix on an interface (make
  before break).  Hard part is making sure new address works with DNS, DHCP.
  Need to keep services reachable.

- Philip: manual effort

- Fred: could be scripted. RFC 2xxx protocol; Cisco didn't implement it 
  because of unsolved problems.

- Ilijtsch: tested on small Cisco router, in specs, i/fs need global addr.

- Tim: see v6ops drafts on using link-local addr on router i/fs.

- Bill Manning: DNS hasn't been touched on. Should discuss how to renumber
  DNS servers.

- Fred: when working on RFC 4192, Cisco person took person aside; UPC
  reader knows address not name of server it reports to.

- Bill: ever tried to renumber a root name server?  Draft isn't specifically
  dealing with caching, resolv.conf.  Needs more emphasis.

- Sheng: Seems this is already documented in gap analysis draft.

- Tim: ping the AD. Additional draft here that we are not chartered to
  produce. Can we adopt this one, or should we extract good text for the
  other drafts.

- Ilijtsch: issue with 2 ISPs, take addresses from ISP A, try to send on ISP
  B and run into source address filtering.  Really need to be able to send
  packets to the right exit to avoid filtering.

- Ron Bonica (AD): work item is about static route configuration problem.
  No protocol being developed.

- Tim: but not in charter currently

- Ron: ok, so finish the docs you are chartered to do, then add this draft
  if/when you recharter.

- Tim: so please ask Brian to extract bits from this draft and put in gap 
  analysis draft.


New work and next steps

- Tim: any additional comments?  Will discuss with Wes about issue arising from
  homenet.  Will focus on the two drafts.


Meeting adjourned