IPv6 Working Group
Vancouver IETF
November 8, 2005
Bob Hinden & Brian Haberman
IPv6 w.g. chairs
Minutes taken by Greg Daley, edited by Bob Hinden.
Agenda:
- Introduction, Call for Scribes, and Agenda Bashing
Haberman, 05 minutes
- Document Status
Haberman, 05 minutes
- 8th TAHI Test Event, Miyata, 02 minutes
- DOCSIS 3.0 and Stateless Autoconf, Droms, 10 minutes
Goal: Raise Awareness
- Considerations on M and O Flags of
IPv6 Router Advertisement, Hinden, 15 minutes
Goal: Consensus on document
draft-ietf-ipv6-ra-mo-flags-01.txt
- IPv6 AdHoc Group Status report, Lindqvist, 10 minutes
Goal: Status report
- Advancing core specification to Standard, Hinden, 15 minutes
Goal: Proposal and discussion
- Future of IPv6 working group, Haberman, 10 minutes
Introduction, Call for Scribes, and Agenda Bashing
Chairs opened the meeting. Greg Daley agreed to take minutes. Reviewed agenda.
Document Status, Haberman
Document status is available at
here at the IETF tools site.
No questions.
Also mentioned there will be a presentation in the L3VPN w.g. that the IPv6
w.g. was asked to review:
It looked like this was trying to create a new kind of site-local
addresses and a new class of global IPv6 addresses.
Pekka Savola asked about status of the consensus call on ICMP name lookups.
Brian: I've had some comments, and I want to incorporate
the comments and get feedback.
Question: In the document tracker, some comments on the (something) of
DNS, have you made any progress on those?
Brian: not yet.
8th TAHI Test Event
Another test event hosted by TAHI. With a new set of tests.
Please make sure that you attend if you've got an implementation,
and document the testing for implementation reports.
DOCSIS 3.0 and Stateless Autoconf
Alain Durand and I have been discussing 2462, i This has grown out of
some work for cableworks for docsis. As we tried to integrate 2461/2
into docsis it wasn't clear how to do this. Fundamental problem is that
addresses can come from lots of places.
Prefixes can come from RAs and DHCPv6. Privacy extensions (different
IIDs, same prefix).
Local configuration: entire IPv6 address or just the IID, combined with
an advertised prefix: like SAA, etc. How are these going to be combined
on a host, how does the host choose. How does an ISP or IT department
show hosts how to do this, and how does the department enforce policy.
There may not be useful trust between hosts and network.
Enforcement issues:
RA can advertise M+O=0, but the host can try DHCPv6 anyway...
Mutual trust...
easy to enforce, DHCP server just does this anyway.
Don't run a relay, or server.
RA can advertise a prefix without A bit,
hosts can do stateless with a prefix anyway.
If an ID dept wants to enforce this: requires filtering at the edge.
Not an administrator assigned address...
If the network administrator wants to enforce that, then the DHCP address
allocation must be used to control/inform filtering.
What does the config mean when coming out of a router?
Started this was RFC2462: there's no 2119 text.
What does the config information mean: mandatory information, or
indicative?
If the config is mandatory, you can trust the device, but you still need
to verify: source address filtering...
Best you can get is that the best is advisory...
M+O advisory. A bit off in RA:
- don't do SAA
- Don't do SAA even with RFC 3041(bis)
- Router is trying to enforce stateful address config,
or is being used with a distributed (administered)IID,
and the prefix is done using
A bit set to false:
Subtle problem:" no RFC 2119 precludes this.
The text in there,
Discussion:
Suresh: No text is defined how the behavior should be configured. No
configuration variable named in the RFC. Ralph: There are other abstract
variables Suresh: you could set policy (distribution) to turn off
autoconf. 10 hosts on the link, and 2 don't autoconf. differential
control of the devices on the link.
Alain: quick response to the first point. some environments where
going back to the router anyway won't be wasteful
Thaler: bunch of original mechanisms... nothing can override static
config. Filtering will be required regardless. Any time you don't use
2119, MUST is implied.
Narten: If there's confusion then that's part of the whole document.
People misinterpreting it isn't really a problem requiring revising the
document. You're going to catch them with the filtering anyway.
Dave Green: Information about filtering would you like something DHCPv6
server sending update rules to the firewall. Properly authenticated.
Ralph: Come to DHC WG meeting this afternoon.
Considerations on M and O Flags of IPv6 Router Advertisement
Goal: Consensus on document
draft-ietf-ipv6-ra-mo-flags-01.txt
M+O bits didn't reach a consensus last time. If we can't reach a
consensus, then we have to do something, as it's not defined in the
current Bis document.
Referred from 2461 discussion. Changing the document may make 2461bis
not a DS.
A lot of discussion on the ML, the draft was doing too much, that it
wasn't meeting the goals. Very little progress since last meeting. no
new draft.
3 requirements were proposed.
- Ability to indicate DHCP is not available,
- Ability to get everything with a single message exchange
- Ability to do DHCP without any routers.
Consensus on 1 only.
Thomas Narten proposed revised text for M+O on the mailing list:
M :
1-bit "Managed address configuration" flag. When set, it indicates
that addresses are available via Dynamic Host Configuration Protocol
[DHCPv6], including addresses that were not configured via stateless
address autoconfiguration. Clients SHOULD use DHC to obtain addresses
(and associated configuration information) as described in [ADDRCONF].
Note that when the M bit is set, the setting of the O bit is
irrelevant, since the DHC server will return "other" configuration
information together with addresses.
O :
1-bit "Other configuration" flag. When set, it indicates that
[DHCPv6lite] is available for autoconfiguration of other (non-address)
information. Examples of such information are DNS-related information
or information on other servers within the network. When set,
- If the M bit is also set, clients SHOULD use DHC to obtain
addresses (and associated configuration information) as described
above.
- If the M bit is not set, clients SHOULD use DHC as described in
RFC3736.
Proposal to WG:
- Adopt this text.
- Put new M&O text back into RFC2461bis
- Drop this as a separate draft.
Discussion:
Dave Thaler: Don't have any objection, need. Never want to use DHCPv6
only for addressing, but not for other information such as DNS. Want to
make sure that M=>O.
Thomas Narten: Who would make the decision not to use DHCP if there were
some other information available.
DT: want to make sure of that
Thomas: DHCPv6 doesn't just give addresses.
DT: Makes sense
Suresh: 4th case: what does it mean if both bits not set. Need to add
text saying M+O=0 means don't do DHCP.
Bob Hinden: Could add a sentence after this. an indication of services,
Discussion:
DHCPv6 protocol allows Server allowed to have options it won't send by
default. O bit may be used to indicate non-default stuff that the host
may request.
Ralph: Don't think it's the intention Possible to send option request
option to ask for this.
No implication: no concept of that in the server.
No way for the client to say it's getting stuff because of O-bit.
Options that fit into that category, current spec only says whether
Narten: keep it simple: ask for everything you may need.
Ralph: Now understand Dave's question
Dave: OK the implication is we'll ask for everything but addresses.
It would be good to clarify that. We need to read the wording to make
sure of that. No explicit description of option request option may be
useful. That's basic DHCPv6.
Ralph: Agree
Alain: you say if M+O=0, then shouldn't bother...?
SHOULD NOT request, unless you have a really good reason,
Bob: listen to your routers.
Alain: write this down:
Jinmei: Comments on the text itself.
This is an update on 2461...?
Thomas: NSS.
Update on 2461, but 2462 also describes this. Decided to remove text
from 2462bis including when M+O bit changes on to off.
When the host should do if there's no RA.
There's some interesting discussion on this.
2462 must assume M+O=on?
if we adopt this proposal, what should we do with
RFC 2462bis. We've simply removed the text
Should we also revise RFC2462bis?
One of the revised documents this should go into, and that both documents
are in sync with each other. Better than doing a separate document.
Document is it worth going in? doesn't matter which one maybe?
Better to not do as a separate to make it a section in 2461bis, but make
sure accords conceptual data structures
Pekka: if M+O=0, hosts will want to try DHCP in any case, SHOULD NOT
doesn't accord with existing reality.
Thomas: Should recommend proper behavior.
Thomas: Want people to not invoke DHCP, because it costs real bandwidth.
JinMei: be sure: RFC 2461 bis add, revise RFC2462bis.
Bob: Need to check 2462
SHOULD may be too strong: M+O is availability of DHCP services.
Basic consensus is that we should not use strong keywords... We need to
confirm that sense to go with that text.
Bob: Make sure this text is consistent with the rest? Have to go look
again at document.
Stig: DHCP client knows that in order to function, needs to be able to
try DHCP ... Some preconfigured routers may not be possible Server on
the same subnet here...
Thomas/Bob: That's why it's should not must,
Thomas: SHOULD --> MAY or we don't say anything at all?
need clarity, want to make sure expectations are known.
Special circumstances for specific devices.
Don't encourage in general.
Bob: Check in general. That the text is good to put back into 2461bis,
and that the additional sentence is added? We'll need to check things in
2461 though...
Feel of room call on that.
Show of hands: quite a few.
Jinmei: don't object to 2461 changes, but 2462 changes may be quite
large, can't necessarily agree.
Bob: it would surprise me if substantive change was required for
2462bis, and it would be a problem in that case. Need to check.
IPv6 AdHoc Group Status report
IAB adhoc groups, can create at any time (like directorate for IAB).
Takes some IAB members and outside experts, formed to handle some issues
around IPv6. Charters for these groups, and why they're here.
Thomas stays in the group, but I'll chair group. Slide stolen off
Thomas' slide in Minneapolis. IAB input forwarded to IANA.
Work items group has discussed: 2 RFCs from the group. RFC 4147, 4159
HD metrics draft-huston-hd-mteric-01.txt.
Some of this discussion in the RIRs. Members going around to all RIRs.
Talking about policies currently being used for allocations.
Special purposes address book.
IANA special purpose allocations, no specifications how to use this
block. RIRs waiting for IAB.
Have a proposal now, draft text to RIRs, general agreement of what to use
addresses for... Will get posted Monday.
Discussion:
Not sure I understand the goal with the IAB group. RIR topics discussed,
why are we doing this in IETF?
Hinden: This block is an IANA allocated block, not an RIR block. No
address assignment for a protocol for example from RIR.
What about 2001::/X is exhausted?
Hinden: Current space is undefined, and the other blocks assigned to
IETF: this is consistent with other allocation strategies.
Thomas: lots of history. hard to debug. Anycast blocks, teredo prefixes,
Where do we allocate this out of? Previously done informally. Unicast
space is the territory of RIRs
We talked about some of these issues, we can iterate on this further to
make sure people agree and understand the basics.
Advancing core specification to Standard
Goal: Proposal and discussion
IESG core protocols as standard... Widely implemented, and
interoperating.
How to demonstrate that significant implementation and interoperation has
been gained.
Margaret: have done homework. Nothing in specific required. Ask working
group? if the WG agrees, goes to full standard.
Bob: thought we had to do more work, like your approach better.
Thomas: Need to make sure that I heard: Thought I heard we don't need to make a case.
Margaret: Came with nothing? asked if we need a report. Answer: We need nothing.
Brian C: IETF wide last call, if agreed to be nonsense by the community
then that's OK..
What are the core specs? are they mandatory to implement?
Bob: No, just my idea, not based on the node requirements, etc
Brian: no relation to Node Requirements document.
Margaret: Documents go one at a time, even if on the same ballot. Anything on DS for full,
Suggest, also try one IPv6 over foo documents.
Alain: DNS (belongs to another WG) , no objection but belongs to them.
Proposal to write IPv6 Status Report. Would contain:
- Summary of implementations
- Host OS, Routers, Switches, Mobile devices, Firewall, etc.
- Applications support
- Web, DNS, SSH, email, SIP, VoIP, Jabber, Network management, etc.
- RIR Allocations
- Backbone Routing
- Routing tables, Routing protocols, etc.
- DNS Deployments
- Root servers, next level, etc.
- Network Deployments
- Commercial, Government, Research
Not 1000 pages, a summary. Links to additional information. A catalog
of things which are done. Talk about how long things have been in place,
O/S support for a day/week/year/decade.
Need volunteers to write this implementation report. People to help
propose and collect information. If you know of something: tell us. If
we've got a volunteer to write this. Point to public documentation of
the network.
Request for Volunteers
Jordi: Collecting information about this for a long time, on the WWW and
in a database...
Some problems with IPv6 core standard... Bugs in 2460? we have some need to fix these...
- Security overview for v6ops.
- Most implementations don't allow overlapping fragments.
- May need a little bit of refreshing, was some resistance in general.
Significant problems in specs (in nodereqs). Most problems not serious
enough to revise the spec. Worry about a lot of changes.
Lots of things would change (personal view) not a good idea to do that
with IPv4. Easiest thing is to not do this...
Taking it to full standard with things that have known problems. Seems a
bit stupid to put out...
Pekka: agree with Elwyn, PS requires no known technical omissions.
consensus in WG that an approach is valid.
Concerned that IETF document will be used to collect marketing material
for implementations?
Bob: Is a fair question, not a draft, RFC etc.
Pekka: not really worth putting too much effort
Brian: an extended implementation report, perhaps.
Thomas: Sympathize with elwyn, trade off covering known ambiguities, or
fix bugs, and going forward.
J??:Take look if there's any significant in the specs (set a short
time frame) to fix.
The report: informational as short summary, which points to a fuller
report
Bob: Not a marketing document
J??: Put that in the draft "this is not a marketing doc..."
Bob: Pooled room if you think this is a good way forward with this, raise
hands (some hands). against (no hands I could see).
Future of IPv6 working group
Some discussion on address selection, updates needed to remove site local
etc...
IPv6 is going on everywhere as should be. No big-ticket items for IPv6 WG.
This be the last face-to-face.
WG not concluded until everything published as RFC. Mailing list as a
discussion location for IPv6. Shepherding activities to go through.
JAK: Proxy ND security. More general problem. Supportive of how to
close down... Not sure how to proceed. Don't know how many people are.
Wouldn't modify plans for the this item
Hinden: Sounds like a security area thing??
Margaret: Where do things go which would come to this group? No sweeping
answers?
Not going to start up another group for that. Going to take a while.
Waiting for documents, mailing lists declaring IPv6 done. specific
extensions and updates etc.
Some WGs like SEND are small and work just on a specific target.
There's a evolution of the tasks to the specific areas.
We'll be doing the same AD evaluations of tasks some through new WGs,
some identified in INT-AREA.
Brian: Lots of things done in this group you'd never do in an internet
area WG.
Bob and Brian thanked the community for the work on IPv6 and specifically
thanked all of the area directors who have help with this working group.
These include Scott Bradner, Allison Mankin, Thomas Narten, Erik
Nordmark, and Margaret Wasserman.
Meeting Adjourned