breakout summary 2, and other topics

[Jun-ichiro itojun Hagino <itojun@iijlab.net>]

[not an official minutes]


enterprise scenarios brainstorming session

plan of action
1. establish drivers that would make an enterprise interested in ipv6 (migration benefits), brainstorm ideas
	get to 80% coverage approach
2. evaluate new/existing scnearios

enterprise drivers/reasons for ipv6
better address space economics
simplified mobility model
simplified operation model
security
ipv6 development
new ipv6 and the 'killer app'

enterprise buliding blocks - arbitrary order
internet data center - server farm
intranet data center - server farm
vpn infra
wan corporate backbone
wan extranet
lan (single site, single routing domain)
network edge devices or perimeter (firewall, mail proxy etc)
connectivity - multi-isp - multi-address
applications inventory
audit/understanding the network mapping

call for more scenarios outside
attempted to list some more scenarios
internet data center - providing access to ipv6 apps/ipv4 apps across isps (v4 and v6)
	outgoing/incoming access
	cross of perimeter
outsourced all/most of corporate backbone and desire to deploy native ipv6
simpler case - entire enterprise move to v6
call for more scenarios

brainstorming session outcome
try to order the scenarios by complexity
	difficulty to define complexity
decided to not order the building blocks
generate a matrix of buliding blocks versus scenarios
	how they apply to different scenarios
		single building/single location
		campus/single location
		campus/multiple locations

connectivity models/use the buildling blocks to create scenarios
	hostv6/nodev6/devicev6 etc
		on v4 lan
		on v6 lan
	lanv6 (island) to lanv6 (island)
		over v6
		over v4/v6
	lanv6 (island) to lanv4 (island)
		over v6
		over v4/v6

simplest scenarios
single location (in an ipv4-constrained region)
don't have a perm/globally routable v4 address
	don't have infrastructure for a server
	for e.g. need "permanent" addrss, aneed peer-to-peer
solution to go to ipv6


---
dhcpv6 stuff(droms)
oeprational issues with dhcpv6

purpose and outcomes
list potential operational issues around dhcpv6
are there other, similar issues?
does each issue require action?
what needs to be done and who should take ownership?
	try not to dig the hole too deep 

dhcp == stateful autoconfiguration??
dhcp is loosely referred to (RFC2461/2462) as "stateful autoconfiguration" mechanism
does this loose reference require clarification?
imporatnt to clarify? - itojun yes.
"0" or ">= 2" could be problem
+ need to fix it.
+ who should fix it? - ipv6wg.

M, O and A bits
A bit set in prefix advert causes SLAAC, independent of M or O bits in RA
M bit set in RA causes DHCP for address assignment (and implies O bit), independent of SLAAC; M bit not set gives no guidance on use of DHCP
O bit set in RA causes DHCP for other configuration (but not address assignment); O bit not set gives no guidance on use of DHCP

net admin restricts hosts to DHCP addresses by not setting A bits in any prefixes
dual use possible (A + M)

thomas: "no guidance" - wording in spec is different
droms: "not set" behavior is not clearly specified
thaler: "M bit indicates whether or not" - so, "M=0" means "no DHCP"
rob: take it to the list.
+ ask on the list if "whether or not" is clear enough
+ send to the list

requirement for stateful autoconf
an IPv6 stack must include stateful autoconf?
required for use when M or O bit set
huitema: manual config is "stateful"
thomas: don't use of "stateful" or "stateless" wording

Q: to be fully compliant, need to implement DHCP?
rob: we don't know enough about service discovery yet
huitema: stateless is a must, DHCP is optional
blanchet: network admin policy decision - orthogonal, should not be a MUST
hain: should implement DHCP, if you claim to support M/O bit
bound: are there requirement for dhcpv4 ever? - no
rob: (1) we end up with the same situation as ipv4 (2) (logger missed) (3) not entirely convinced about service discovery part
+ O bit, "information other than addresses" is not clear
huitema: "O" bit means "you may want to get config info from stateful config mech".
huitema: how about MAY on M bit and MUST on O bit?
itojun: how about MAY on M bit and SHOULD on O bit looks okay
rob: multiple protocol for same service does not work well
+ some need for further discussion
+ which mailing list? - ipv6wg

authentication for DHCPv6
evolved from RFC3118 (DHCPv4 auth)
incorporates input from steve bellovin
keys now include:
	DHCP realm for roaming
	lifetime and key selection for key rollover
if it is not good enough for you, let us know.
thaler: it is needed for addr stuff, it is not needed for other stuff

how do we go describing in dhcp spec, clients and server does O bit style of config?  simple-dhcp?  "this part of protocol spec is mandatory?"
huitema: dhcp-lite profile?
+ dhcp-lite (mandatory part) - dhcp group issue

inconsistencies between dhcp and other sources
preferred and valid lifetime on advertised prefixes do not apply to addresses assigned through dhcp (*)
other inconsistencies are not fatal and are resolved by "latest information wins"
(vaguely related question) are these three questions equivalent?
- not advertising a prefix
- advertising a prefix as not on link
- letting the lifetime of a prefix expire
itojun: misconfiguration
thaler: don't think so
bound: latest wins (RA overrides DHCP info)
thomas: authenticated DHCP info, vs unauthenticated RA info
bound: stateful/stateless configured address doesn't mix
+ (*) put toghether clarification for the result - lots of hands for "yes"
+ consensus - needs some work at ipv6wg 

dns configuration
net admin can select DNS resolver autoconfig with O bit not set and DNS resolver config through DHCP with O bit set
requires stack MUST have DHCP for use with O bit set
rob: what happens if there are tons of other service discovery ways?
itojun: MUST is too strong, SHOULD may be okay
itojun: what if dns server address is not available from dhcp?
hain: ??
huitema: we do have several config protocols. dhcpv4, dhcpv6, dns-slv, slp.
huitema: O bit, no way that we can say in the ipv6 spec what to do.  should be documented in application specification (DNS/whatever).  what to do against O bit should be specified per-protocol manner
hesham: O bit "try dhcp, then blah"
thomas: application protocol specifies O bit behavior does not seem to work
huitema: dhcpv4 vs dhcpv6 - how to resolve conflicts?  who?
mar: only purpose of O bit is to tell you "don't use DHCP"
thomas: original rationale is to avoid dhcp delay optimization
rob: we don't see a need for this bit
rob: whole bunch other of synchronization issues in multiple protocols
+ need to revisit O bit description
+ go to ipv6wg

SLLAC and DHCP from same prefix
does current DAD specification protect against conflict among SLAAC addresses and DHCP assignment from prefix adverrtised with A bit set?
should there be a recommendation against DHCP assignment from an SLAAC prefix?
thaler: "yes" to first line (2nd line - no)
huitema: RA tells you how long you can use an address, ...
+ go to ipv6wg

reserved interface identifiers
should there be a recomendation against assigning dhcp that use any resreved interface identifiers?
thaler: reserved anycast addr
?: u bit, g bit
+ if you can think of other items, let me know

(itojun)
snmp - 0.0.0.0 (IPX)


wrap-up
charter changes - need to talk to randy, that's all