Minutes for 6MAN at IETF-88
minutes-88-6man-1

6MAN Working Group - Vancouver IETF Meeting
Monday, 0900-1130, 4 November, 2013, Regency D

Chairs: Bob Hinden, Ole Troan (remote from Norway)

Minute taker: Fernando Gont
Jabber scribe:  Michael Richardson

Jabber Room: 6man@jabber.ietf.org 

Meetecho: http://www.meetecho.com/ietf88/6man

Slides can be found at: http://www.ietf.org/proceedings/88/6man.html

-----------------------------------------------------------------------
Agenda
-----------------------------------------------------------------------

Introduction, Agenda Bashing, Document Status, New Charter, Chairs, 15
min.

Updates to the IPv6 Multicast Addressing Architecture,
draft-ietf-6man-multicast-addr-arch-update , Stig Venaas, 15 min.

Efficiency aware IPv6 Neighbor Discovery Optimizations,
draft-chakrabarti-nordmark-6man-efficient-nd , Samita Chakrabarti, 15
min.

Wireless Neighbor Discovery Stateful Address Identification and Location
exchange, draft-thubert-6man-wind-sail , Pascal Thubert, 15 min.

SSAS: A Simple Secure Addressing Generation Scheme for IPv6
AutoConfiguration, draft-rafiee-6man-ssas , Hosnieh Rafiee, 15 min.

Packet loss resiliency for Router Solicitations,
draft-ietf-6man-resilient-rs , Suresh Krishnan, 10 min.

Privacy Considerations for IPv6 Address Generation Mechanisms,
draft-ietf-6man-ipv6-address-generation-privacy , Alissa Cooper, 20 min.

Deprecating EUI-64 Based IPv6 Addresses,
draft-gont-6man-deprecate-eui64-based-addresses , Fernando Gont, 15 min.

Speed Talks (5 Minutes, 3 slides)
---------------------------------

IPv6 ND Option for Network Management Server Discovery,
draft-liu-6man-nd-nms-discovery , Bing Liu, 5 min.

Identifying Addresses of IPv6 Tunnel Packets at Tunnel Exit-point,
draft-liu-6man-ident-tunnel-packet-addr , Cong Liu, 5 min.

IPv6 Tunnel MTU Configuration, draft-liu-6man-tunnel-mtu-config-00 , Cong
Liu, 5 min.

The Subnetwork Encapsulation and Adaptation Layer (SEAL),
draft-templin-intarea-seal-65.txt , Fred Templin, 5 min.

Operational Issues Associated With Long IPv6 Extension Header Chains,
draft-wkumari-long-headers , Ron Bonica, 5 min.


Introduction, Agenda Bashing, Document Status, New Charter, Chairs, 15
min.
-----------------------------------------------------------------------

Bob opens the meeting, and Ole goes through document status.  Ole and Bob
go through the New 6man charter.  

Ted Lemon: Double-checking that milestones will be added for the items
being discussed in the previous slides.


Updates to the IPv6 Multicast Addressing Architecture,
draft-ietf-6man-multicast-addr-arch-update , Stig Venaas, 15 min.
-----------------------------------------------------------------------

Bob asks for comments, and asks whether people have read the document
(some hands, not a lot).  Bob notes that this document does a good
thing. We should get a reviewer and then WGLC.  Ole asks for volunteers
to review the document. Jinmei and Suresh volunteer.


Efficiency aware IPv6 Neighbor Discovery Optimizations,
draft-chakrabarti-nordmark-6man-efficient-nd , Samita Chakrabarti, 15
min.
-----------------------------------------------------------------------

Brian Carpenter: I'm confused by your 64-bit unique ID, that you
introduced to handle multiple-address hosts. It's not clear if it's an
interface identifier or something else. You hint that there might be
networks were there might not be EUI-64.. you need to be more specific
regarding how you create this if there's no EUI-64.

Erik Kline: What happens registration fails or is denied? Can the client
fall back to advertise itself with DAD?

Samita: If address registration fails, it client should try to go to
another default router if available... the client should be able to keep
track of who they are,. If one fails, it should try another one.

Erik Kline: That might mean that the client might need to register with
many routers (e.g., multiple provisioning domains). This is very
complicated. This could be used as a mechanism for operators for deny
you more than one address. Mixed mode SHOULD be supported but is not
required.

Erik Nordmark: If you do mixed mode, it actually works falling back.
If you want to move to a place where you're not doing mixed mode, where
the router registration information is the authority, you don't have to
send any multicasted NSes ever. Then you're not going to have mixed mode.

Erik Kline: What's the harm in having a fall back?

Erik Nordmark: You will always have to deal with unknown IPv6 addresses
by sending multicasted NS to see if anybody is there. It would be nice
to get to the point where you don't have to do that. Would be nice to
throw everything at the router: if the address is not in my cache, it
doesn't exist. Period. Can people use this to prevent you from using
multiple addresses? Sure. But they can do the same thing by enforcing
filtering.

Erik Kline: It would be possible to create a network where you can
register with only one address.

Erik Nordmark: There's nothing in the spec that says that you'd reject a
registration based on some policy. An implementation can always say if I
already have a registration and I receive another registration request,
I can replace the existing one or reject the current one. There's
nothing that says that such implementation is incorrect with respect to
the standard. The only difference with this protocol is that it has
explicit signaling with respect to adding entries to the neighbor cache.

Erik Nordmark: Follow up to Brian with respect to the 64-bit IID. Not
sure if that was related to the /64 discussion. Anyway, we need to
separate between two registrations from the same host for the same
address from two registrations from different nodes for the same
address. For that we need some uniqueness value. And when this was done
in 6lowpan, people started to use EUI64 for that... but has nothing to
do with the length of the prefix. This is separate from the /64
discussion. We can deal with any length of the subnet length.

Pascal Thubert: Agree with Erik that the limit on the number of addresses
is already present in e.g. SAVI, so this is not changing anything in
that respect. If you compare this model with DHCP, with DHCP you have to
go to the server to get your address. In DHCP, you apply your policy on
every request. In this protocol, applying a policy would be the
exception rather than the rule. As we progress this, we have to look at
error codes, and suggest what should be the "plan B" based on the error
code.

Samita: The policy could be implementation dependent or deployment
dependent, which would be hard to specify.

Ole asks whether we're ready to make a call for adoption. Weak hum in
favor of adoption. None against. To be confirmed on the mailing-list.


Wireless Neighbor Discovery Stateful Address Identification and Location
exchange, draft-thubert-6man-wind-sail , Pascal Thubert, 15 min.
-----------------------------------------------------------------------

Brian Carpenter : There is a comment in the Security Considerations that
says that the use of EUI64 precludes the use privacy techniques.
My question is why you say you cannot use privacy techniques.

Pascal: Should review that.

Michael Richardson: Is this the canonical "I know where this address
is in an arp-ish network"?

Pascal: Yes.

Erik Kline: We seem to be pushing a lot of complexity to the clients to
deal with a variety of network scenarios. We're complicating the
protocol and the client. Did we have have this problem with IPv4? If we
didn't, should we throw ND and go back to ARP?

Pascal: It's already screwed with v4, but it doesn't show so much. v6
can make it even more, because we send more multicast messages.
Regarding complexity, I don't think this is much additional complexity.
IPv6 brings in the scale problem, because with 64 bits you grow the
subnet to an immense scale, as opposed to the small IPv4 subnet. The
problem is not IPv6... initially the problem is multicast and scale.

Eric Vyncke: I see a field named "trust" in this slide, which kind of
relates to security, but I don't see any kind of signature notification
in this message.

Pascal: This draft in particular doesn't say how you do it, but clearly
if these messages are in trusted they must have been secured in some way.

Erik Nordmark: Response to Erik Kline: We're trying to take v6 where we
have not taken v4, like 6lowlpan. If we move across those types of
networks without changing my IPv6 address we need to have something that
can scale up to that. We haven't solved that for v4. The interesting
questions is what is the state of wifi in terms of the impact of arp vs
Neighbor Discovery. Would be good to have some data from operators.
Question to Pascal: This draft still refers to the backbone router...
are you planning on pulling in all of those pieces, or are we having
another backbone draft with other use cases and other pieces of this
puzzle?

Pascal Thubert: My call would be discuss how you do proxy ND over the
backbone as a separate draft. If think that if we put this, efficient,
and backbone router in the same document it's going to be crazy.. but we
have to discuss that.


SSAS: A Simple Secure Addressing Generation Scheme for IPv6
AutoConfiguration, draft-rafiee-6man-ssas , Hosnieh Rafiee, 15 min.
-----------------------------------------------------------------------

Ole asks how many people have read the document... he counts about 4
people.  Bob asks for comments.

Erik Nordmark: There reason I thought was interesting is that these
local attacks might become more prevalent. If we can address the
backhaul/longhaul security issues, if people use more and more public
access, man in the middle attacks might become more popular, and these
local attacks might be the weakest leak. Trying to lock down the address
mapping would be important. A fair question that has been asked is "Why
would this be deployed if SEND?" hasn't? That's a fair question and the
answer maybe that people don't care that much about security to
implement and deploy it. This is simpler and more efficient than
SEND+CGA. If we don't add this to our toolbox, we might not find a way
out should thing get significantly worse in terms of these attacks. I
encourage people to look at this, and see if this makes sense to
implement, etc.

Bob encourages the wg to read this (not many folks have). Once we get
reviewers, we can do a wg call for adoption.


Privacy Considerations for IPv6 Address Generation Mechanisms,
draft-ietf-6man-ipv6-address-generation-privacy , Alissa Cooper, 20 min.
-----------------------------------------------------------------------

Ole asks for comments.

Brian Carpenter: Very useful and informative stuff. I wonder how many
bits in the IID for the IID to be opaque. e.g. most of the 64 bits?

Alissa: We want to separate the mechanism from the prefix length.

Brian: But if someone wanted to change the prefix length, they should
have this into consideration.

Erik Nordmark: Opaqueness is not a binary quality. We should also
consider how the IID is tied to the prefix. We should make sure it's
cryptographically hard to map one prefix/IID into another prefix/IID.

Kerry Linn: I have a point and a confusion. The point is that at times
tracking must be useful (in some scenarios). The confusion is that
EUI64s were supposed to be useful to have a globally-unique identifier.
With respect to the /64, how many bits do we need to have such uniqueness?

Fernando Gont: Those are unrelated issues. When it comes to embedding
the MAC addresses, it has already been found that there's a lot of MAC
address duplication, so you cannot really really on the MAC addresses for
uniqueness.

Ole Troan: Do you think that the scope of the document could be such
that you could recommend how these addresses should be used? e.g. a
server not needing temporary addresses, etc.

Alissa: The draft would explode if we did that... and I'm not sure if it
would be possible to enumerate all cases. And in many cases the
recommendation wouldn't be obvious.

Ole: Maybe the app area should work on this? e.g. an app might have for
different types of addresses available and would need guidance with
respect to how use such addresses, and which addresses should be made
available by the hosts to the applications.

Bob: There's a void and we need to fill it. Guidance should be provided.
We cannot just provide a discussion of the properties of these addresses.

James Woodyatt: Regarding CGA, it could also change when the modifier is
regenerated. It's also the case that the subnet ID is employed in
generating the key.. hence the addresses would be stable but not
constant. You should also distinguish between publishable and referable.
Referable being "published in some small community". e.g. stable
addresses might be publishable.. but temporary might be referable, but
not publishable. Another point I'd like to make is that MAC addresses
are not guaranteed to be unique. The OUI just specifies who administer
that bloc of the address space. But the address is not necessarily unique.

Michael Richardson: Two things. Is there a prohibition here for a host
to prohibit the generation of EUI-64 IIDs?

Alissa: Not at all. That's the next document.

Michael Richardson: It's useful to have the MAC address as an asset ID.

Bob: Let's leave that for the next document.

Tim Chown: Good document. Good to publish as informational.


Deprecating EUI-64 Based IPv6 Addresses,
draft-gont-6man-deprecate-eui64-based-addresses , Fernando Gont, 15 min.
-----------------------------------------------------------------------

Dave Thaler: I want to compare this to is the process we went through
with site locals. At the time, it was implemented, there were valid
uses, but we deprecated it anyway. If you look at the document that
deprecates site locals "some are going to use them even if we deprecate
them". The question I have to Michael and all, is you didn't have this
available in IPv6. Is this really some shiny thing that if we were to
remove you'd say "IPv6 is no better than IPv4".

Jen: Even if you replace MUST NOT with SHOULD NOT, that's still two
strong. Because some people rely on this feature. The security concerns
could be addressed without this change. I can live without this feature,
but I like it.

Fernando Gont: Among the possible ways forward is to just recommend a
more sane default. And if you have a really good use case for Modified
EUI-64 IIDs, you just override that default. Besides, how can you
possibly address these security/privacy concerns without this change?

Jen: If we make this change, we leave the door open to changing the
subnet size. People will think that they can use interface identifiers
that are not 64-bits long.

Fernando: These are completely unrelated issues. People can think
whatever they want -- we cannot prevent that. For instance, Microsoft
has been doing something else, and they still comply with 64-bit
interface identifiers.

Alex Petrescu: You've discussed what the draft does not require, but it
is not clear what it requires and what it deprecates.

Fernando: We're saying that nodes should not generate interface
identifiers by embedding a hardware address.

Alex Petrescu: Can I use something else for the IID, such as a plate number?

Fernando: Yes, you can. But we recommend that the default is
draft-ietf-6man-stable-privacy-addresses.

Alex Petresescu: In IPv4 we had NATs. In IPv6 it is probably less
recommended to use IPv6 NATs. So we need to be able to generate
addresses starting from something. You don't want that?

Fernando: We just don't want to embed the MAC address in the IID. As an
example, Microsoft uses a different scheme that generates addresses
automatically, without embedding the MAC address.

Alex: Are you recommending Microsoft scheme as the default?

Fernando: No. We're recommending
draft-ietf-6man-stable-privacy-addresses. We're just referencing
Microsoft approach as an example of an implementation that deviated from
the standard to mitigate these issues.

Erik Kline: I'm well on board with all caps "SHOULD" for this stuff.
However, I don't see the value for changing this for link-local addresses.

Fernando Gont: When it comes to link local addresses, they might leak
out. e.g., you connect to a local MTA on the local link, and that
addresses might leak in the email headers.

Erik Kline: Doing this for link-locals seems a bit excessive.. it could
be even "MUST" for global addresses, but "SHOULD" for link-local.

Fernando Gont: I could live with that.

Andrew Yourtchenko: I agree with Erik Kline. For some nodes, it's fine.
For other, e.g. servers, it's different. For example, I may want to
predict what's the address that the server. Right now I can do that by
writing the MAC address on the box.

Samita: I agree with the previous speakers. For backwards compatibility,
the default should be the current scheme, but it should it possible to
override it to make it private.

Fernando: I don't think there's any backwards compatibility issues. This
is a local policy. It's not a change to the protocol. It's a local
policy that you can implement in whatever way you want.

Tim Chown: A few points. What you're suggesting is that there are
several ways to generate IIDs. It's not clear how you'd apply your policy.

Dave Thaler: Four points. First, a general comment: Far more useful than
"I'd like EUI-64" is "I have this use case that I cannot do without
them". There's an analogy here with the deprecation of site locals,
where there were some valid use cases. The wording that there is in the
site local deprecation document is that, standardization-wise, they are
deprecated, and hence new implementations are not required to implement
them. Maybe we should look at the site local deprecation document and
see if there's wording that everybody likes. Regarding the use cases,
the only one I've heard is the inventory use case. Regarding enforcing
these to link-local addresses, there are cases where they suffer the
same issues. e.g. there's the example that Fernando mentioned. Another
is that at times an application my send addresses for e.g. referrals,
and send all addresses... and the same issues apply. It's possible that
this sort of thing might happen with MAC addresses... but it's far more
common with IPv6 addresses. Another is that in some subnets, the
link-local addresses may go further than MAC addresses. I don't like
that, but people often do it.

Erik Nordmark: A SHOULD should normally be followed with a reason for
which you might not follow the advice. And that language can be made as
strong as we want. The language for globals may be different from that
of locals, with a warning of what might happen if you do it. Another
thing is that it might make sense to make it clear that this is just
about stable address and not about temporary addresses. Regarding the
use case for servers, we use to ship boxes with MAC addresses or
barcodes in them so that they could pre-provision their systems before
opening the box. I don't know how common is this today.. they probably
don't want to tie the system to the MAC addresses, because if the card
breaks, they are going to replace that card. Anyway, this case could be
addressed as follows: when the vendor burns the box, they generate the
stable address and print it on the box along with the MAC address, and
problem solved.

Suresh Krishnan: One comment against the MUST NOT. There's a header
compression in 6lowpan that might stop working if we make this a MUST
NOT. We could either say "screw those guys" or "relax this".

Brian Haberman: Just want to channel my IESG colleagues. There are no
interoperability issues so... SHOULD, MSUT etc don't make no sense.

Alain Durand: I'd like to talk about the inventory case. We've been
asked by customers to do this... so I'd like that this inventory case
makes it into the document.

Ole asks for hums in favour of adoption. There seems to be support for
adoption. Will confirm on the mailing-list.  Bob notes that adoption does
not mean that the recommendation is frozen.  The wording will be
discussed as part of the process.


Packet loss resiliency for Router Solicitations,
draft-ietf-6man-resilient-rs , Suresh Krishnan, 10 min.
-----------------------------------------------------------------------

Suresh summarizes the changes, and notes that folks should check whether
everything's okay.

Dave Thaler: I don't have an answer, but want to rephrase the question
so that folks may have an answer to it. What does it mean for Router
Discovery to be successful? Does it mean that you got a response from
one router, or that you got a response from all routers?  And if you
think it's the latter, how do you known.

Ted Lemon: I thought you already had it in the document.

Suresh: Do we want to prohibit sending further RSes once an RA is received?

Ole: What does RFC4861 says?

Suresh: It doesn't say much. It says you send a RS when the interface
goes up.

Ole: Even if you receive a RA after the first one?

Suresh: You stop after the first one.

Erik Nordmark: The operational/network load question here is. When the
information you have times out, you should go back to sending RSes
again. If I knew three routers and now hear one, I may one to send more
RSes.... but... do we really want to have all devices send this
background RSes?

James Woodyatt: I think there's a real problem here, but maybe the
answer to Dave Thaler is that routers may indicate whether hosts should
continue soliciting after they get RAs.

Erik Kline: This is a difficult thing to answer. There might be multiple
operators on a link, each with their own router advertising not a
default route but an ARO for special services, and if one of them says
"stops after getting a default router", it would be tricky.  I guess my
question for Brian Haberman is is this an interoperability issue? i.e.,
you already have connectivity..

Ole: Existing implementations are going to reply to each of your RSes,
and this is going to be a load problem and control plane issue.

Brian Haberman:  The key to take away from RFC2119 is that they are
supposed to be used to ensure interoperability.

Suresh: In this case is implementation guidance.

Brian Haberman: In that case, be very careful. Because people's
impression from what those keywords mean from an implementation
perspective is different from they impression of what they mean from an
interoperability perspective.

Ralph Droms: The problem here is that nobody has a list of where all the
routers are. Suppose routers listen to RAs so that each of them comes up
with a list of what they think is the complete list of routers, and they
all send out. In that case you might tell whether you have heard from
all of them.

Suresh: This is the kind of stuff we did for DNA a while ago.. but it's
very complex...

Bob asks for reviewers of this document.


---------------------------------
Speed Talks (5 Minutes, 3 slides)
---------------------------------

IPv6 ND Option for Network Management Server Discovery,
draft-liu-6man-nd-nms-discovery , Bing Liu, 5 min.
-----------------------------------------------------------------------

XXX: I didn't see in the I-D what NMS stands for. And if you mean for
routers to give this information, rather than any neighbor, which would
be a bad idea.

XXX: Erik Kline what are the alternatives today for disseminating this
information?


Identifying Addresses of IPv6 Tunnel Packets at Tunnel Exit-point,
draft-liu-6man-ident-tunnel-packet-addr , Cong Liu, 5 min.
-----------------------------------------------------------------------

Jinmei Tatuya: It would be helpful if you described what current
implementations do.


IPv6 Tunnel MTU Configuration, draft-liu-6man-tunnel-mtu-config-00 , Cong
Liu, 5 min.
-----------------------------------------------------------------------

Erik Kline: 1240 would be a vaild IPv6 link? I'm not sure you can just
make the MTU less than the IPv6 minimum MTU.


The Subnetwork Encapsulation and Adaptation Layer (SEAL),
draft-templin-intarea-seal-65.txt , Fred Templin, 5 min.
-----------------------------------------------------------------------

Ole: Isn't the whole point of the minimum MTU of 1280 bytes that since
most links are 1500 bytes, you have 1500-1280 bytes for encapsulation?

Fred: For that assumption to be true you have to have a careful
orchestration of the MTUs of the link. Let's take this to the mailing list.


Operational Issues Associated With Long IPv6 Extension Header Chains,
draft-wkumari-long-headers , Ron Bonica, 5 min.
-----------------------------------------------------------------------

Dave Thaler: Routing Header does not belong here. You must process it
only if it is destined to you. I that case, you're kind of proxying --
i.e. regenerating the packet.

Ron: This may need to go to enhanced.

Tim Chown: Both Fernando Gont and I have done some tests with respect to
extension headers and fragmentation, and briefly talked about it
yesterday at IEPG... and the statistics of the amount of packets that
are dropped if you do longer and longer headers chains is startling and
similar if you employ fragmentation.

Ole: Can you send it to the mailing-list?

Tim: We're pushing some short article, but I can send a summary of the
stats.

Ron: I'd love to reference those stats.


-----------------------------------------------------------------------
Meeting Adjourned
-----------------------------------------------------------------------