6MAN Working Group - Stockholm IETF Meeting Minutes

Wednesday, July 29, 2009, 1300-1500
Chairs: Brian Haberman, Bob Hinden

Jabber Room: 6man@jabber.ietf.org
Meeting Room: Small Stage

Minutes taken by Aleksi Suhonen

Agenda

All presentations can be found here .

1. Introduction, administrivia, agenda bashing

Brian Habermann opened the meeting at 13:01 CET DST. There were no objections to the proposed agenda. The status of the documents in progress looks good.

2. Node Requirements Update

Ed Jankiewicz gave an update on draft-ietf-6man-node-req-bis-03.txt.
On the slide "Privacy Extensions (RFC4941)":
Dave Thaler: "no benefit to stationary servers or routers": There ARE benefits to these, if they make outgoing connections.
Tony Hain: Made the same point
Ed: I blame the power of making short power point slides.
Tim Chown: Did propose changes to wording on the mailing list that would have indicated what you want to do instead of what you are.
Shin Miyakawa: CPE Routers act as host toward the upstream but router toward downstream. 5.7.2: text says that host can do it but router can't, can CPE do it then?
Brian&Suresh Krishnan: router/host role should be made per-interface
Shin: The text says "a node that is not a host is a router", should be changed.
Behcet Sarikaya: Is route optimization going to be removed from the doc? I don't want it removed.
Suresh: It has been tested, but it has not been deployed and there's controversy whether it will ever be deployed. SHOULD may be overkill.
Brian&Bob: Does everyone agree about making the doc an applicability statement?
Dave Thaler: Agree mostly, but don't call it "applicability statement" because it has bad connotations to some people and they might not read it.
Bob: But having that status would let us do things we couldn't otherwise.
Bob: Poll of room: lots for, one against, no majority.

The chairs believe there is a concensus to have the Node Requirements update be given a status of "Applicability Statement"

3. Line identification in IPv6 Router Solicitation messages

Suresh Krishnan gave a presentation on draft-krishnan-6man-rs-mark-03.txt
Document is also discussed inside Broad Band Forum (BBF).
Ralph ??: Not needed with routing CPEs, why? Change wording: (didn't catch the rest)
Dec Wojciech: How can it be compatible with SEND?
Suresh showed how he's gotten it to work from the backup slides.
Gabriel Montenegro: Seems to be very specific to a particular setup. Why is it on the standards track?
Suresh: Because we need to get an option number assigned.
Gabriel: Maybe...
Pekka Savola: Is the assumption that if there is no LIO, the router will ignore you? What if the CPE is not upgraded or the CPE is a bridge?
Suresh: The option is added in the Access Node, so it doesn't matter what devices there are or what they do at customer premises.
Drom: It's like dhcp option 82.
Mark Townsend: Why not use unicast RA?
Suresh: W...
Erik Nordmark: Even tho this is specified for a particular setup, it will end up being used elsewhere too, so it should be defined with that in mind.
Mark: BBF has this 1:1 vlan model that solves this.
Bob Paraphrasing Erik: If BBF breaks something, they should fix it themselves.
? Takia: What is the LIO used for inside the router?
Suresh: Different prefixes.

4. Line identification in IPv6 Neighbour Solicitation messages

Hongyu Li gave a presentation on draft-li-6man-ns-mark-00.txt

Woj: This work has NOT been formally requested by BBF.
Bob: There's a side conversation on what's the relation
Erik Kline: They created a layer violation and its unreasonable to expect us to fix it.
Woj: Will the router also send NSes?
Li: No
Woj: downstream insertion is bad
Mark: This is a subset of all deployment models. They hacked IPv4 to make it work, and now they want to hack IPv6? Shouldn't the bad deployment models rather be scrapped? But then again, if we don't do it, will it be a big hindrance to IPv6 deployment? I don't have an opinion, I am just raising these questions.
Erik: You could...
Mark: Yes, let's give some constructive feedback to BBF. "We don't like that, have you thought of this?"
Krishnan: The DSLAM does not often have an IP address.

5. A Recommendation for IPv6 Address Text Representation

Seiichi Kawamura gave a presentation on draft-kawamura-ipv6-text-representation-02.txt

Thomas Narten (from Jabber room):

15:03 < Aleksi Suhonen> could you go and ask this question: "When trying to search ipv6 addresses: why not define a new data type for ip addresses that could bend much better to this problem and subnet matches and so on..."
15:03 < Aleksi Suhonen> instead of doing it in text format
15:04 < Aleksi Suhonen> it would be useful in SQL, XML

Tim: It should be useful in vi.

15:03 < narten> another solution: convert string to its 16-byte on the wire format, then do the comparison. wire format is then the canonical representation.

Randy Bush: Going for informational so "no harm done". I need stuff like this for operational issues. Thank you for this.
Marc: Have you thought about updating RFC4291?
Suresh: I had issues with this document, but now i think it's OK and should go forward.
Ed: What's wrong with RFC1942.
[missed this comment about dotted decimal format.]
Thaler: I think a canonical format is useful. Need also do "address:port" format.

Brian: Poll of the room "should this be adopted?"

Good concensus to adopt it as a wg doc, will ask on mailing list.

6. The UDP Tunnel Transport mode

Godred Fairhurst gave an update on draft-fairhurst-6man-tsvwg-udptt-01.txt

Margaret Wasserman: I would prefer the 0 checksum approach rather than this one. This creates a new header type and more work for NAT boxes and other such beasts. I don't feel this solves the problem without creating a new one.
Gorry: UDP checksum 0 -> you can't get ICMPv6 back
Margaret: Why not?
Gorry: Where would it be sent to?
Margaret: Well, with two IP headers in the tunnel stack, you have two different places anyway. I don't want to have accidental (error?) messages sent to the wrong places.
Erik N: With UDP there are two lengths, IP len and UDP len. By checking if the lengths you can identify that it's one of these.
Dave Thaler: This looks very much like UDP Lite.
Gorry: The difference is that this one doesn't do a length check. Lite requires an integrity check which causes a problem for us.
Thaler: Is it safe to use the same header? THIS may cause the problems. Middleboxes might drop bad packets. I would prefer the 0 checksum draft.
Marshall Eubanks: Both drafts have the middlebox issue. Which one is more likely to break more? (addressed to the floor)
Margaret: I thought more about the ICMP problem. There's a security concern here if you send the response to the address in the wrong header (outer vs inner).
Marshall: Margaret: Does the other draft already address this issue?
Margaret: The other draft doesn't have an inner header and an outer header, so there is no ambiguity.

Bob: Chairs' view of where to go next: need more discussion on the mailing list.

7. Considerations of address selection policy conflicts

Arifumi Matsumoto gave a presentation on draft-arifumi-6man-addr-select-conflict-00.txt

No time for comments.

8. IPv6 Address Selection Design Team

Tim Chown gave an update on draft-chown-addr-select-considerations-03.txt

Brian: Poll for adopting as wg doc?

Good consensus for adopting as a 6man working group document. Will confirm on the mailing list.

9. Adjournment

The meeting was adjourned at 14:56.