[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
breakout summary 2, and other topics
- To: firstname.lastname@example.org
- Subject: breakout summary 2, and other topics
- From: Jun-ichiro itojun Hagino <email@example.com>
- Date: Fri, 20 Sep 2002 09:04:51 +0900
- Delivery-date: Thu, 19 Sep 2002 17:05:15 -0700
- Envelope-to: firstname.lastname@example.org
[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
new ipv6 and the 'killer app'
enterprise buliding blocks - arbitrary order
internet data center - server farm
intranet data center - server farm
wan corporate backbone
lan (single site, single routing domain)
network edge devices or perimeter (firewall, mail proxy etc)
connectivity - multi-isp - multi-address
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)
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
connectivity models/use the buildling blocks to create scenarios
on v4 lan
on v6 lan
lanv6 (island) to lanv6 (island)
lanv6 (island) to lanv4 (island)
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
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
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
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?
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
snmp - 0.0.0.0 (IPX)
charter changes - need to talk to randy, that's all