IPv6 WG Minutes

[Brian Haberman <brian at innovationslab.net>]

All,
     A big thank-you to Suresh Krishnan for taking minutes.  Please
send corrections to these minutes by March 22, 2005.

Regards,
Brian


IETF 62 ipv6 wg meeting minutes
===============================

People referenced in minutes
============================
Brian Haberman (Brian)
Margaret Wasserman (Margaret)
Jinmei Tatuya (Jinmei)
Pekka Savola (Pekka)
Alain Durand (Alain)
Bob Hinden (Bob)
Rob Austein (Rob)
Hideaki Yoshifuji (Hideaki)
Mukesh Gupta (Mukesh)
Dave Thaler (Dave)
Elwyn Davies (Elwyn)
Thomas Narten (Thomas)
George Michelson (George)
Bill Fenner (Bill)
Stig Venaas (Stig)
Mark Andrews (Mark)
Olafur Gudmundsson (Olafur)


Agenda and Document Status
==========================
Brian Presenting
No one had any comments on the Agenda during Agenda Bashing

Jinmei has a comment on the Doc status. He wants to know next steps for
2462bis as ADs need implementation status reports .

Margaret needs info if former impl reports apply (just checking to make 
sure).
Also need statement from chairs and pointer to the old impl report to 
this
effect. Mukesh Gupta (Mukesh) wants to know if the implementation 
reports are
needed for the ICMPv6 revised draft as well. Brian clarifies they are 
needed
for both ICMPv6 and for 2461bis. He also clarifies that they are not 
needed
if the existing implementations are not affected. The loosening of algo 
for
privacy addrs, for example, has no effect on existing implementations. 
Pekka
thinks the reports are so general, that is hard to infer anything 
specific
from them.Margaret thinks that they may not be complete but they were 
good
enough for the first time. IESG will not force to redo a new format for
the Implementation Reports

ULA update
==========
Margaret presenting

She has no slides. She already sent the info to the ML.

IESG review found an issue with the DNS section. The issue was the 
increased
load due to reverse lookups on DNS. Added text to resolve this.The text
Reverse queries MUST NOT be sent out of the site.

Alain is worried about how this will be implemented on the routers or 
on DNS
servers? Mark thinks that basic premise is that this
traffic should not leave the site and must egress filter it and must 
tell the
client it does not exist. He said para had MUST in upper case.Brian and
Margaret think that this is operational guidance and cannot use 
normative
language.

Alain and Pekka think that if it needs to be in a DNS implementation it 
needs
to be normative. Alain wants a separate document addressing the dns 
related
issues and does not want this text here. After discussion between Alain,
Margaret, and Bob agree to have the issue mentioned both in the ULA 
document
and another separate document. Rob clarifies that this text does not 
apply to
centrally assigned ULAs, which most likely will have a real reverse 
tree.

Alain thinks we need a BCP document containing the list of prefixes. 
Brian
agrees with Alain. We have a problem which is holding up this doc. That 
is
what we are fixing. We cannot wait for another doc to go all the way 
during
the process.Margaret thinks there are 3 options 1) get the text in this 
doc
and publish it2) wait for the other document and add a norm reference 
to it
3) do nothing. Alain: thinks there is a 4th option 4) take great care 
in this
and point to an informative reference. He refers to RFC1918 that had 
text
which said don't put this on the net. that does not work. We will have 
legacy
clients still generating queries. We need to fix this in the servers

Pekka is worried about the effects this will have on caching resolvers 
that
every host needs to be modified. Olafur feels that this will cause least
damage as opposed to not doing this. Margaret: It does not hurt you any 
more
if you get a no from your ISP rather than from the root server. Rob 
thinks
we need to pick a default (pass or don't pass). This is the lesser of 2 
evils.
Make it a config option. we should not harm the public net. Pekka is
concerned whether the people who use ULA will see it the same way.

Pekka: It is just not clear, that the people who use ULA will see this.

Jinmei and Alain don't want this work to be done in the IPv6 wg. Rob and
Mark also think this should be done in the DNS space in the long term 
and
this is a short term fix.

Brian wants to use this text as a rough guideline and asks for a show 
of hands.

(CONSENSUS CALL)
Who wants to see this text in the doc? about 15 hands
Who does not? one or two hands
(CONSENSUS IN FAVOR)

Alain thinks the second question was a bit loaded.

Brian rephrases Q2 to be "Who does not feel this text should in this 
document
and be in another document"? 3 hands

Update to address arch
======================
Bob presenting
It was approved as DS. There was an appeal. To resolve the appeal it was
published as PS. There is most likely an implementation report already. 
The
main changes were to resolve issues raised in Robert Elz's appeal and to
deprecate site local. There were also a few mainly editorial changes. 
Bob
will remove confusing text in the multicast scoping part of the 
draft.Pekka
wants compatible addresses removed from the spec. Tim agrees. Bob 
thinks there are
people who still want them in. Pekka feels that there was no consensus 
on ML.
We should get the consensus here. Bob thinks that we should probably 
leave
it alone as we are recycling an exisiting standard.

(CONSENSUS CALL)
Brian
Q1) Who wants to remove of ipv6 mapped addresses.
(no hands)
(CONSENSUS AGAINST REMOVAL)
Q2) compatible addreses
who wants them to be removed? 20 hands
who does not want it removed? 3 hands
(CONSENSUS IN FAVOR OF REMOVAL)

Hideaki does not want compatible addrs removed. He wants the address 
space
not to be reused. He is ok with deprecation.

(CONSENSUS CALL)
Bob: Do we want to deprecate them? about 10 hands
No? 1 hand
(CONSENSUS IN FAVOR OF DEPRECATION)

2461bis
Brian to be Hesham
==================
The last major issue left is the processing messages without the SLLAO 
option.
Will be adding text from Greg Daley to clarify this case. Will make 
sure that
Hesham will send the propsed changes to ths list. Jinmei and Greg agree 
to
take it on the list

(Reordering of presentations)

icmpv6
======
Mukesh presenting

Major changes are
* text to allow disabling of sending Destination unreachable messages 
will be
added as a SHOULD
* will remove security replated processing details for icmpv6 packets 
and add
an informative reference to 2401bis. There is a downref issue if this 
needs to
be done.
* New text for source address determination from Elym to be included as 
2.2 (b)
instead of 2.2 (b),(c) and (d)

Discussion between Suresh, Bob, Dave, Elwyn and Pekka on whether the 
sender
should try to make the error message more informative when the the 
receiver
might not know this or may not want to know this. Pekka thinks that 
adding
this as a SHOULD will cover the existing implementations

Pekka the previous SHOULD will cover the existing
implementations

ndproxy
===========
Dave presenting

Dave talks about why we need ndproxy and what are the characteristics of
ndproxy. The doc is aimed to be EXPERIMENTAL. Loop prevention was a 
major
issue in the ML discussions. Added text to say loop prevention is a MUST
(and allow two ways to do it STP / physical constraints)

Erik had a new suggestion (P bit in RA)
-> if clear and on upstream proxy would set and forward on downstream
-> if set or on downstream the proxy would disable proxy func on that 
interface
for some time.
hold down time of 2*maximum RA interval = 60 mins

now the draft has 3 options (P/STP/physical constraints)

Bob suggested the option (c) - physical constraints should be removed 
and the
authors agreed. Pekka agrees with removing (c). Suresh is concerned 
that if a
network contains some ndproxies which use the P-Bit and some which use 
STP
there will be an issue. Greg suggests adding an appendix clarifying 
this.

SEND interoperability is another issue which remains. Dave talks about a
draft draft-daley-send-spnd-prob-01 which talks about the scenarios
send is not a blocking issue as long as the draft is consistent. The 
explicit
requirement for send interop has been removed.

Alain wants to know if this is related to trill? Brian thinks it is not 
and is
independent.

IAB ipv6 ad-hoc committee report
=========================
Thomas presenting

RIRs were starting to request large allocations from IANA(>/23). IANA 
wanted
advice from the IAB. The ad hoc committee was formed to advice IAB on 
ipv6
addressing matters

Related drafts
Format of the IANA registry huston-ip6-iana-registry-05
ip6.int deprecation huston-ip6-int-01

Alain wants to know if there are stats for number of queries for 
ip6.int as he
is concerned about the impact of doing this to existing equipment.
Thomas does not have them. George has info collected over 2 years. He 
will
make the info public, but he said the volume is pretty low but not 
trivial.
George thinks that there will be some impact but we must not overstate 
this.

Thomas thinks allocating /23s to RIRs is not a good idea for 
agrgegation. The
RIRs think /12 or /16s are better. He also thinks that we need to have 
a good
balance between aggregation and conservation (in ipv6 the balance is 
more
towards aggregation). The IETF interested in long term stewardship, and 
not
day to day management. We need to get good aggregation over time

Currently each RIR has its own policy but they should converge on same 
process
before going forward. We need to document technical considerations of
allocation sizes, reservations etc. huston-ipv6-hd-metric-00 needs 
community review

Pekka thinks is not appropriate to discuss it here. Thomas and Pekka 
kind of
agree on v6ops.

Bob announces that Thomas is retiring as AD. Thomas has been active a 
lot in
the ipv6wg. Bob wants to give him a big hand.

(The crowd goes into WILD APPLAUSE)

Thomas has had a lot fun and is continuing to have fun


ipv6 scope identifiers in URIs
==============================
Bill presenting

There is an issue with representing IPv6 scope IDs using URIs as % is 
used
to introduce % encoded chars. There are three ways to go about fixing 
this

1) Use a non-% character which fits existing grammar: We cannot copy 
and paste
2) Use %25 :It needs update to uri spec and we still cannot copy and 
paste
3) Continue to use % : Does not fit URI spec. Exception to fundamental 
URI rule

Dave thinks Scope IDs appearing on the wire is a bad thing. Bill agrees 
with
him. Margaret thinks these are being used in some docs the IESG has 
passed.
Dave thinks this is OK to do as long as they are not called URIs. 
Margaret
agrees with Dave. Brian, Bob, Mukesh think there is some utility for 
this.
Jinmei is not convinced. Stig thinks there is no need to cut and paste 
as
these URIs will only be used internally by applications. Brian wants to
continue discussion on the ML as time is up.

(END OF MEETING)

Attachment: smime.p7s
Description: S/MIME cryptographic signature

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------