6MAN Working Group - IETF 84, Vancouver
Wednesday, Morning Session I 
0900-1130, Room Name: Regency C
Chairs: Bob Hinden, Ole Troan
Minutes by:  Suresh Krishnan


Agenda bashing
==============

The chairs presented the agenda. There were no comments on the agenda.

Document Status
===============

Dave Thaler provided an update regarding 3484bis. He will be adding a
small changelog entry into the draft. He had gotten a private query
about returning sorted source dest pairs instead of xxx. Dave was
inclined to say it is out of scope and, since the proposed change was
non-trivial, not appropriate to do in AUTH48. He would be willing to
work on a followup document to do so.

Suresh Krishnan presented the draft about Packet loss resiliency for
Router Solicitations,
(draft-krishnan-6man-resilient-rs-01.txt)
======================================================================

Mark Andrews agreed that the problem was real and it needed a real
solution. He had seen an issue with Macs completely losing their
default route and connectivity when some RAs were lost. 

Simon Perreault also agreed that it was a real problem and had seen it
many times. He sees a need to agressively send RSs initially, but once
an RA is received he wants the sender to stop. Suresh clarified that
the algorithm is intended to solve this issue for both broadcast links
as well as NBMA links where the RA can only be received as a result of
sending an RS.

Kerry Lynn also supported this work from the homenet context. He
believed that this change would serve to reduce support calls and was
hence a good thing. He believed that there were no links that IPv6
would not be enabled in, since an IPv6 enabled node on such a link
would form a link-local address and start communicating with other
such nodes on-link. Suresh clarified that the open issue in the draft
was targeted towards links that did not have an IPv6 router.

Lorenzo Colitti thought that this was a good idea and supported this
work. He also wanted to know the thoughts behind the current algorithm
of try thrice and give up. Erik Nordmark explained that this algorithm
was derived from RFC1256 (Router Discovery). Lorenzo also believed
that DHCPv6 transmitted more often than once per hour (the maximum
interval that this draft was intending to use). Suresh clarified that
there was some work ongoing to increase this maximum retransmit
interval for DHCPv6 Solicits to 3600s. Lorenzo 

Tim Winters talked about some scenarios where the host implementations
would receive an RA but the RA did not contain the information the
host was looking for and asked whether the case to allow the host to
transmit RSs even after receiving the RAs was considered. Suresh
responded that this was considered but was left off to handle at a
future date. i.e. not as a first step.

Fernando Gont liked the idea and he wanted to know what would be the
destination address of the RS. Dave clarified that the IPv6
destination address was always the All Routers multicast address and
this got mapped into different link layer destination addresses baded
on the link type (NBMA or Broadcast capable). He also clarified that
this specific draft does not change the the addresses.

Thomas Narten thought that this was good work and he supported it. He
believed that, in retrospect, this should have been done when the
original ND work was being done. He also wanted the RS retransmissions
to continue until a router is found and did not want the host to
"conclude that there are no routers on the link". He mentioned the
situation 15 years ago where lot of wireless links wanted to avoid the
overhead of such retransmission but he had not heard such comments
recently. He thought that this could be disabled per link-type if needed.

Tim Chown (jokingly) remarked that for links with no IPv6 there should
be a DHCPv4 option that signals that IPv6 is not available.

The chairs asked for a hum to gauge wg interest in adopting this draft
as wg item. The working group was in favor of adopting the draft as wg
item. This will be confirmed on the mailing list.

Bob Hinden presented the draft about Representing IPv6 Zone
Identifiers in Uniform Resource Identifiers,
(draft-ietf-6man-uri-zoneid-02.txt)
======================================================================

Erik Kline wanted to know if the authors have considered '@' as a
separator. He also wanted to know how to ensure that the zone id was a
valid production. Bob mentioned that it cannot be ensured. Dave Thaler
mentioned that in windows the zone id was always an integer but it
could be different for other OSs.  

Stuart Cheshire wanted this to be mentioned in the document as a
guideline to OS implementers. He wanted to do what was best for the
end users rather than what was best for the programmers. He believed
that unless the zone id was greater than 250 there were no issues. Bob
Hinden agreed with Stuart and thought that browsers could easily
handle the special case.

Dave Thaler thought that the whole justification about cut and paste
was dubious, and he wanted the justification to be rewritten
concerning other issues with using %. He talked about the validation
of the stuff inside [] performed by RFC4007 validators. He wanted to
make sure that he could reuse the validation code instead of writing
two sets of code that could introduce bugs. Juergen Schoenwaelder did
not see the value with using a new separator either.

Stig Venaas wanted to mention that the % could become ambiguous if %
escapable characters are already present in the interface names. Dave
mentioned that if the text has any foreign characters cut and paste
would not work anyway. Mark Andrews agreed with Stig concerning this
being confusing to humans but not for computers.

Stuart and Kerry thanked Bob for taking on this tough job.

Bob believed that the authors had enough information to do another
revision with the comments received during the meeting.

Teemu Savolainen presented the draft about Optimal Transmission Window
Configuration Option for ICMPv6 Router Advertisement,
(draft-savolainen-6man-optimal-transmission-window-00.txt)
======================================================================

Dave Thaler wanted to know what the advantage was to do this in v6
instead of an L2. Teemu mentioned that the information was needed on
the LAN and not on the L2 WAN.

Bernie Volz wanted to know why the gateway wouldn't just delay the
packets. He thought that it would be much easier that way.

Philip Mathews had seen similar issues with NAT traversal
keepalives. He was not in favor of doing this in IPv6. He would like a
more general protocol to do this.

Lorenzo Colitti wanted to know the power consumption of the WAN radio
in relation to sending WLAN beacons. For this to work all the apps on
the LAN link would need to understand this information. He proposed
instead that the app use a DSCP combination that will allow delaying
the packet at the gateway. Teemu promised to send measurements to him
and the mailing list.

Erik Kline thought that this was a layering violation and was not in
favor of doing this. He also wanted to know how this can be propogated
inside a home network that was downstream from the cellular gateway.

The chairs wanted the discussion to be continued on the mailing list.

Stig Venaas presented the draft about IPv6 Multicast Address Format
With Embedded IPv4 Multicast Address,
(draft-ietf-mboned-64-multicast-address-format-02.txt)
======================================================================

Brian Haberman wanted to point out that most of the use cases
mentioned for this draft have not been substantiated. e.g. How often
was inter-domain multicast used.

Bob Hinden thought this was a bad idea. He was not convinced that
there is any real application here and he thought that changing IPv6
to help certain translator implementations is not a good idea. In
short this was a very big change for very small benefits and it went
against the original IPv6 design principles.

Stig did not think that the draft changed the address format, but the
draft only restricts the prefixes that people can use. He did not like
using the flag bit either.

Behcet Sarikaya wanted to use well known prefixes. Stig mentioned that
this would not work with Embedded RP.

Erik Nordmark was a bit ambivalent about this proposal and mentioned
that the original design assumption was that there would be a 10 year
period of dual stack use. 

Tim Chown mentioned that interdomain IPv6 multicast with Embedded RP
worked very well and is in use at US and European research networks.

Tom Taylor mentioned that IPv6 sending to IPv6 was the only case that
requires co-ordination but the other cases did not need co-ordination.

Chairs asked the wg if it believed that there was a problem that
needed to be solved.

Brian wanted the chairs to clarify what the problem was. He wanted a
clear definition of the problem before doing any work. Stig wanted to
communicate the wg's opinion to mboned to get them to further refine
the use cases. Brian agreed with Stig.

Thomas Narten wanted to identify the customer(s) and the problem first
before working on the solutions. Simon Perreault mentioned that there
was a draft in softwires that required this work.

Behcet talked about the impact of this draft on the address
architecture and mentioned that was the reason for 6man to get
involved. 

Alain Durand mentioned that he had customers with IPv6 networks who
have video solutions that run on IPv4. So he wanted this problem to be
solved.

Fernando Gont presented the draft about Security Implications of
Predictable Fragment Identification Values,
(draft-gont-6man-predictable-fragment-id-02.txt)

Ole Troan wanted to make this document more generic and discuss the
implications of using predictable values in Internet
protocols. Fernando 

Bob Hinden wanted to see a longer list of OSs. He was also curious as
to whether this was problem that needed to be fixed in IETF or was
this already common knowledge.

Erik Kline wanted to know if there was an IAB document that
recommended the use of non-predictable values if there was an integer
field that did not need specific values.

Thomas Narten was not sure what to do with this. This fell under the
category of "don't do anything stupid". e.g. Why do a document for
IPv6 for things that were well known in IPv4?

Lorenzo Colitti thought that this work was not harmful and should be
pursued irrespective of any iab work.

Brian Haberman did not want to have a point solution for every field
and he would like to see a more general document applicable across the
IETF. Fernando was concerned on whether implementers would read this
generic document. Brian believed that this generic document could be
referred to in the node requirements document, thus ensuring that IPv6
implementers would read it.

Joel Jaeggli thought that it was a worthwhile activity to look at
existing implementations and flag this as a potential issue that was
common across multiple implementations. Thomas Narten and Erik Kline
agreed with Joel.

Dave mentioned that RFC4732 (Internet DOS considerations) talked about
using unpredictable values for session ids. Fernando talked about
other issues discovered after 4732 that still had this issue. Dave
believed that this sort of work needs to be done by the saag and if
this was included in a statement from saag as something to look for in
SecDir reviews, it would have the largest impact.

Chairs wanted to continue discussion on mailing list and requested
Fernando to discuss potential changes with Joel J.

Fernando Gont presented the draft about Current issues with DNS
Configuration Options for SLAAC,
(draft-gont-6man-slaac-dns-config-issues-00.txt)
======================================================================

Thomas Narten wanted to know more about the oscillation
problem. Fernando clarified that the lifetime for the DNS server was
related to the RA interval.

Lorenzo Colitti wanted to match the dns info to the router lifetime
instead of RA interval.

Dave Thaler pointed to the IAB document on config principles. It talks
about mechanisms being self configuring or using a general purpose
mechanism such as DHCPv6. RFC6106 was done to be backward compatible
with hosts that did not have a DHCPv6 stack. He did not buy the
motivation for a receiver side fix and was not in favor of this work.

Alex Petrescu wanted to know if an analogous solution like T1 and T2
for DHCPv6 will be used here. Fernando will think about it.

Erik Nordmark pointed to text in RFC4861 about routers ensuring
consistency amongst themselves (by listening to RAs) instead of
putting the burden on the clients.

Joel Halpern wanted to make sure that new information was always
handled and never ignored. He did not agree with the document's
recommendation to do so.

Chairs would consider doing this as an errata on RFC6106. Discussion
to be continued on the list.

Fernando Gont presented the draft about Managing the Address
Generation Policy for Stateless Address Autoconfiguration in IPv6,
(draft-gont-6man-managing-slaac-policy-00)
======================================================================

Lorenzo Colitti mentioned that if there was a need to control the host
it had to be accomplished by using a managed host configuration
mechanism, and the host would ignore network provided hints. He
thought the mechanism specified in the draft was the wrong way to go
about solving the problem. Dave Thaler agreed with Lorenzo and
mentioned that it was unlikely that he would implement it in Windows.


Hiroshi Kitamura presented the draft about Corresponding Auto Names
for IPv6 Addresses, 
(draft-kitamura-ipv6-auto-name-02.txt)
======================================================================

Stuart described an optimization to the algorithm that could reduce
two hex characters in the name down to one.

Discussion to continue on ML.

Bing Liu presented the draft about DHCPv6/SLAAC Address Configuration
Switching for Host Renumbering,
(draft-liu-6renum-dhcpv6-slaac-switching-01.txt)
======================================================================

Dave Thaler clarified that M=1 was a hint implying there was a DHCPv6
server present and M=0 did not imply nothing.

Jinmei Tatuya agreed that there was a gap in the specs and he was
generally happy with closing the gap. He mentioned earlier work that
failed due to wildly differening opinions people had about what these
flags meant.

Alex Petrescu believed that two flags were not enough. Paul Muchene
tested DHCPv6 and SLAAC on Windows and Mac and had experienced similar
problems.

Lorenzo wanted to either properly define the M and O bits or get rid
of them. Bob mentioned that there was a long discussion a few years
ago and the conclusion was that these flags were hints and nothing
more.

==============
END OF MEETING
==============