Subject: [Autoconf] Updated IETF 75 meeting minutes

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 1 Sep 2009 11:30:56 +0900

Hi

We revised the meeting minutes and updated it, however
the proceeding of IETF75 has been already fixed.

I attach the minutes updated by Ronald.
You will find the detailed discussion of the link-local address  
support in the minutes.

Thanks Ronald for your help.

ryuji

===========================================================
Working Group:	Autoconf
Date & Time:	Monday 27th July 2009 15:20 to 16:50
Chairs: 		T.H. Clausen & R. Wakikawa

Minute-taker:	Christopher Dearlove (with additions by Ronald in 't Velt)
Jabber-scribe:	Thomas Clausen / Ulrich Herberg

===========================================================

[Note: In the text below, DT stands for Design Team, not for Dave
Thaler :-)]

Ryuji Wakikawa: proposed agenda
- Short update on WG status
- Update from Design Team (main agenda item)
- Short discussion on next steps
No changes to the agenda brought forward

Working group Status and Update (R.Wakikawa):
Slides:	http://www.ietf.org/proceedings/75/slides/autoconf-0.pdf

	DT planned -00 draft in April and WGLC July,
	actually -00 draft July, and still as individual
	submission.
	(draft-baccelli-autoconf-adhoc-addr-model-01)

	This meeting, principal agenda item is discussing
	this draft.

	Running slightly late w.r.t. charter. WG is supposed to finish
	this work by September.

DT Presentation (Emmanuel Baccelli)
I-D: 	draft-baccelli-autoconf-adhoc-addr-model-01
Slides:	http://www.ietf.org/proceedings/75/slides/autoconf-1.pdf

	Two main topics covered by DT draft:
	1 - What is an IP Subnet in a MANET?
	2 - IP address configuration

	- Link level connectivity not stable, subnet reduced to
	  single interface and address.
	- Recommended solution configure /32 or /128.
	- Addresses unique in routing domain
	  (required by some routing protocols),
	- Addresses may need to be globally unique.
	- Configured addresses unique within routing domain.
	- Open questions
	  + Configuration of additional addresses.
	  + What is the "MANET Link Model".
	  + Can we use Link Local addresses.
	  + Do the addresses have to be globally unique.

Discussion

	Dave Thaler
		- Consistency with RFC 4291 (in particular section 2.5.1).
		- Do you believe you have 64-bit interface identifiers that
		  are unique within the subnet prefix? (the 64-bit part being
		  a requirement for all unicast addresses that do not begin
               with binary '000').
		- If the answer to previous question is 'no', do you require
		  prefixes to start with binary '000'?
		- If that is not the case either, shouldn't the document say
		  that the addressing model will not be compliant with RFC4291?

	Emmanuel Baccelli
		- Document does not specify which address ranges to use.

	Thomas Narten (on Jabber)
		- There is no reason why Autoconf should not use EUI-64-based
		  interface identifiers.

	Dave Thaler
		- If you believe that you ARE compliant with RFC4291, the way to
		  phrase it is, that you have a /64 subnet prefix, but it is only
		  assigned to a single host.

	Mark Townsley
		- Aim to be consistent with RFCs.
		- Beyond scope of document, may need to go that far.

	Ralph Droms
		- Document uses same wording for IPv4 and IPv6: "subnet prefix
		  configured on interface"; this is really IPv4 terminology, in
		  IPv6 you have a list of prefixes and an indication of whether
		  those prefixes are on-link or off-link.
		- Careful wording, to the effect that no prefixes are on-link, can
		  solve the IPv6 case.
		- For the purposes of this document, adopt similar wording for the
		  IPv4 case, even though this kind of formalism is not commonly
		  used for IPv4.
		- Distinguish subnet and prefix.

	Fred Templin
		- Do we need an address other than link local on an interface?
		  Propose obtaining an address and putting it on a virtual interfaces
		  and have only link-locals on the MANET interfaces. Then we have what
		  RFC1122 refers to as link layer multiplexing. This works for single
		  physical interface as well as multiple physical interfaces  
attached to
		  to same MANET. For IPv4, you can use link-locals per RFC3927 on the
		  physical interfaces.
		- Will write this up on the Autoconf ML.

	Emmanuel Baccelli
		- Have read Fred's VET document, but deep architectural considerations
		  were not the goal of DT document. Rather, provide a simple model for
		  address configuration.

	Fred Templin
		- If DT document says use /32's and /128's, I may not want to do that
		  on my MANETs. Might not fit all cases.
		- Can you have multiple interfaces on a router attached to the same  
MANET?

	Thomas Narten (Jabber)
		- What Fred Templin describes is what I thought the Autoconf model  
was for
		  normal addresses. They are either on a virtual interface or on a  
separate
		  real interface, like an Ethernet. Addresses on the MANET interface  
are
		  only for making the MANET work.

	Mark Townsley
		- Right now just talking about addresses that make the MANET work.  
Should
		  say this more clearly in the document.

	Fred Templin
		- Agree multiplexing does not need to be in this document, since it is
		  already in RFC1122.

	Mark Townsley
		- As a general principle: Because you can do something doesn't mean  
you have
		  to do it.  More choices fixed, the easier the job is for the  
solution
		  that AUTOCONF is to deliver in the end.

	Fred Templin
		- As long as you don't stipulate that I have to put a /32 or /128  
global
		  address on the MANET interface. Multiple ways to run a MANET.

	Mark Townsley
		- But there should be only one for autoconfiguration, lest
		  one would end up with a very chattery protocol in order to
		  try to figure our (for a new router) "which of the multiple
		  ways is deployed in this network now?".

	Fred Templin
		- If there is only to be one way, prefers his approach.
		- Proposed /32 on VET interface. Has it been discussed by DT?

	Teco Boot
		- First simple case, MANET router with single interface.
		  With multiple interfaces more complicated. Optimizations later,
		  maybe in a separate document.

	Fred Templin
		- Disagrees his approach is complex.

	Thomas Clausen
		- There are some characteristics needed to make routing protocols
		  work. There are several ways to satisfy this. Identify what are
		  the requirements. Document does this. Agree with Mark Townsley
		  that need to decide what to do. Applications should see things
		  as normal, i.e. only a/the routing protocols should be even
		  aware of the existence of a MANET.

	Henning Rogge
		- Don't think it's good idea to put multiple interfaces on one
		  side as solution for single interface may not work for multiple
		  interfaces, which are common. Not clear that link local addresses
		  for interfaces can solve all problems.
		
	Emmanuel Baccelli
		- Much discussion within the DT on the use of link locals. No  
conclusion
		  reached yet.

	Thomas Narten (Jabber)
		- Keeping all issues open will mean that WG will get nowhere.
		  Choosing a baseline does not exclude other possibilities.

	Jari Arkko (on Jabber)
		- Yes, need one model. Think of it as an example. We don't outlaw  
other
		  ways, but cannot cover all possibilities with a single model.

	Ralph Droms
		- Problem with link-local addresses is, that they are *assumed* to
		  be on-link.
		- What about ULA? Or a reserved centrally-assigned ULA prefix that
		  can be uniformly not marked as "on-link".

	Erik Nordmark
		- Two things to decide up front:
		  1. IF link local addresses are used, what would their semantics  
be? To
		     me it seems that they should only be sent on the actual link.  
MANET
		     routers should not forward them. Other people might have  
different
		     opinions.

	Thomas Clausen
		- Isn't it defined that you should never forward LL's?

	Erik Nordmark
		- Unless back onto the same link. You could try to finesse that in
		  the MANET space, but let's not do that.
		- 2. What are the addresses that you actually auto-configure?
		     I think those are essentially non-link-local addresses, whether
		     ULAs for IPv6 or anything else. We still have the issue of
		     physical versus virtual interfaces. It would be good if an
		     autoconf protocol were designed to cater for both.

	Thomas Clausen
		- Doesn't that depend on your assumptions with respect to the
		  virtual interface? What the virtual interface will be used for, e.g.
		  to bind applications to it?

	Erik Nordmark
		- Two different cases. The first one is like a loopback interface
		  on a router; it only needs a single address. The other one is the
		  interface behind you which has a full subnet prefix. That's
		  actually not a virtual interface, but the question is whether the
		  autoconf protocol can also be used to configure the prefix on that
		  interface or whether you need a different mechanism for that.

	Emmanuel Baccelli
		- Interesting question, but beyond the scope of the DT document, which
		  concentrates on what's needed to make the routing protocols work.

	Erik Nordmark
		- Intended as directions for the WG. People do want to do things  
differently,
		  but we don't want a separate protocol for each possibility.

	Ralph Droms
		- My earlier point on link-locals was, that if you want to use  
addresses from
		  a prefix that is not marked as on-link, you cannot use them,  
because they
		  are assumed to be on-link by default. That's why I suggested using a
		  reserved ULA.

	Mark Townsley
		- Can we make a decision? Don't see much value in a link local  
address.
		  Rather have a global address. Hate to see MANET deployed and  
unable to
		  get to an interface from outside the MANET. Link local only if  
easier.

	Thomas Narten (Jabber)
		- Ralph: There is more to this. I think (wonder?) if folk are making  
an
		  assumption that if they have a link-local prefix in their routing  
table,
		  then normal packet sending (involving LL addresses) just works. By
		  saying use a /128 for "on-link", they prevent LL addresses that are
		  not actually neighbors (because they are MANET addresses) from being
		  routing. [sic] Which is good. But this is too simplistic. You can't
		  just put a LL prefix in your routing table and make things work. If
		  you have multiple interfaces, you can't tell from just looking at a
		  LL address which interface to send the packet out on.

	Fred Templin
		- Some applications may need a Link local just as state on the  
interface,
		  even if never used as source address. Not talking about routing  
protocols.
		- VET interface as virtual interface can encapsulate or not as  
required.
		  Take a look at the draft.

	Thomas Clausen
		- Requests link to document on ML. However, not all in scope for
		  Autoconf. Is it being discussed in INT Area?.

	Fred Templin
		- Document in RFC editor queue as individual submission, but now
		  created a bis version, that has specifically this proposal. Now
		  aiming for an INT Area submission.

	Dave Thaler
		- On the question whether you can use link-locals, I agree with what
		  Ralph said: No, you would want ULAs or similar. In order to specify
		  that, you'd have to be tricky, though. RFC4861 (like RFC2461 before)
		  contains a statement that all interfaces on routers MUST have a
		  link-local address. To still be conformant, you'd have to say that
		  you *have* a link-local address, but that's different from using it.
		  That's why I say you have to be tricky with what you specify to
		  avoid having to revise other RFCs.

	Emmanuel Baccelli
		- Seems like we have more or less covered the open issues from the DT
		  document.

	Mark Townsley
		- Question for room, should we target autoconfiguration of global
		  addresses for interfaces for operation of the MANET? Should these
		  adresses be global, local, both? Should these addresses be
		  reachable from the Internet?

	Emmanuel Baccelli
		- Document concentrates on first phase, getting addresses for making
		  the MANET routing work. Connectivity to/from the outside world comes
		  later. However, if you get global addresses right away, you solve  
two
		  problems at once.

	Thomas Clausen
		- Routing protocols can handle addresses of any scope. Just happen to
		  have considerable experience with using /32's and /128's.
		- Let's make a decision.

	Christopher Dearlove
		- Do want to address nodes in the MANET from outside.
		- Hope we make a decision, then even those whose first choice it
		  wasn't will work with it.

	Jari Arkko (Jabber)
		- I'm in the focus-on-globals camp. (If you are taking hand counts...)

	Dave Thaler
		- Have argued against link-local, but as to global or ULA - don't  
overspecify.
		  Not concerned about individual interfaces not being "pingable"  
from the
		  outside world. We already have that today with ISATAP and nobody is
		  screaming.

	Fred Templin
		- Can use link-local for physical interface, global for
		  virtual (VET) interfaces.

	Thomas Clausen
		- Disagree. Some routing protocols need to know which physical  
interface a
		  packet was sent on.

	Mark Townsley
		- Agree with Dave Thaler. Don't specify global or ULA now.

	Teco Boot
		- I partly agree on not overspecifying what's being used by specific  
protocols.
		  There *are* protocols that require link-locals also for MANET. For  
example,
		  an ND Router Advertisement, which may be used in a MANET, MUST
		  use a link-local source address; OSPF MUST use link-locals. I  
suggest that we
		  do not break these protocols by specifying ULAs or globals. I am  
not saying,
		  that we don't need ULAs or globals. Nobody disagrees with this.  
But let's not
		  specify that we don't use link-locals anymore. They are very  
practical for
		  some protocols and they can be used without problem.

	Thomas Clausen
		- It's not a matter of forbidding something, it's a matter of  
specifying *a*
		  practical addressing model, as per the charter.

	Mark Townsley
		- The more things you have to configure, the more options you have,  
the harder
		  it will be. Take some things of the table.

	Teco Boot
		- Let's take of the table whether or not to use link-locals for  
routing
		  protocols. When there are routing protocols in place that use them  
and they
		  work well, let's not prohibit that. Let's go forward, let's work  
on globals
		  or ULAs, but if link-locals are there and they're being used,  
that's OK.

	Erik Nordmark
		- Is the suggestion that link-locals be configured in the way  
they're being
		  done today in an IPv6 host or router just based on the MAC  
address; that
		  they can sit around there and maybe something will use them, like  
sending
		  RAs? Or is the suggestion that the autoconf protocol will be used to
		  actually configure the link-local addresses? Those are two very  
different
		  things. In one case you just pick it off of your MAC address. It is
		  locally unique on your link with whoever happen to be your  
neighbours at
		  that millisecond. You could use it to send packets, which will not  
be
		  forwarded by any routers. It's a very local thing, this link-local.

	Thomas Clausen
		- At a later point, as the network evolves, your link-local may no  
longer
		  be unique unless you do some magic.

	Erik Nordmark
		- The other way people *could* think of link-locals is something  
that could
		  be used for a multi-hop MANET routing protocol, where I could look  
at
		  something that came from a link-local source and know that that's  
3 hops away.
		  That's a very different model.

	Thomas Clausen
		- Nobody should think of link-locals as being visible more than 1  
hop away.

	Erik Nordmark
		- Another aspect is, what are the uniqueness criteria?

	Thomas Clausen
		- That depends. If I want to run my MANET routing protocol, using as  
the
		  endpoint identifiers link-local addressses, then the requirement  
is for those
		  addresses to be unique. I cannot accept duplicates.

	Erik Nordmark
		- That depends on the routing protocol.

	Thomas Clausen
		- The routing protocols that the IETF has standardized or is in the  
process of
		  standardizing, for MANET.

	Erik Nordmark
		- Other protocols like OSPF have a Router ID, that you get from  
somewhere else.

	Thomas Clausen
		- The current crop of MANET protocols do not have that. For link  
detection, to
		  detect bi-directionality, I need both ends of a packet  
transmission to be
		  able to identify over which interface the packet was sent and  
received.
		  Unless I have a way of uniquely identifying those interfaces, the  
routing
	        protocols won't be operating correctly. If that identifier is  
a link-local
		  address, then that address has to have the property of uniqueness  
at least
		  within a two-hop scope. Other protocols may have other requirements.

	Erik Nordmark
		- It's one of those zero-one-infinity things. It's one thing saying  
this is
		  unique when I run DAD, a millisecond later it might not be unique.  
Whether
		  you say I want this to be unique as the MANET evolves and other  
nodes come
		  into reach OR you say I want it to be two hops instead of one.  
That's a
	        completely different ballgame.

	Thomas Clausen
		- It needs to be unique within two hops AND it needs to be unique  
over time
		  as well. Whether link local or not, it must have those properties.
		  Otherwise you are going to break the MANET routing protocols.

	Teco Boot
		- Property only of OLSR, NHDP, not of DYMO, OSPF. It's not defined  
how to
		  autoconfigure a Router ID for OSPF.

	Thomas Clausen
		- It is required that you can uniquely identify each interface,  
communications
		  endpoint.

	Teco Boot
		- Only for those protocols, not for a bunch of others.

	Thomas Clausen
		- Even in OSPF you are able to uniquely identify a given interface.  
But you
		  use a router ID and interface number.

	Teco Boot
		- For OSPF, this has nothing to do with link-locals. The interface  
ID is just
		  a number local to the router. Your statement is true for OLSR, for  
NHDP, but
		  not true for other protocols. Let's be accurate.

	Mark Townsley
		- If we are to have *one* autoconf protocol, we need to choose the  
lowest common
		  denominator. If one protocol needs something, then need to provide  
it.

	Erik Nordmark
		- There is another point we should capture. You might want to send a  
Router
		  Advertisement for whatever reason. There is no reason to forbid  
having a
		  link-local address, as long as you state what the semantics of  
that address are.
		  It is only unique on the link the moment you tested it. It might  
be non-unique
		  a millisecond later. It means nothing beyond the first hop, ever,  
and packets with
		  those addresses don't get forwarded by any router. As long as you  
state all that,
		  somebody designing a new routing protocol can decide whether to  
use those
		  addresses or not. It seems many routing protocols need something  
better than that.

	Fred Templin
		- Agree. IPv6 interfaces can have multiple addresses. No guarantee  
that link-locals
		  stay unique. They can be probabilistically unique, if we do e.g. a  
CGA assignment
		  or a MAC EUI-64 assignment. Just putting a link-local there,  
doesn't mean we are
		  going to use it for a purpose that requires uniqueness.
		- Can put MANET local addresses, as previously considered, on  
physical interfaces
		  and global address on the virtual interface.

	Thomas Clausen
		- Agree with the latter.

	Mark Townsley
		- Can allow link local - but only if doesn't make the autoconf  
protocol more complicated.

	Erik Nordmark
		- That's why I want to make sure we write this down in the document,  
even if it is a
		  duplication of what is already written elsewhere. Uniqueness  
properties, the fact
		  that they are not forwardedi, etc.

	Thomas Clausen
		- (Persuades Erik to contribute strawman text for the above on the  
Autoconf ML).

	Fred Templin
		- Minor point: with IPv6 you can have LLs and globals on the same  
interface. With IPv4,
		  you're supposed to remove link-local addresses when you have  
addresses of greater scope.

	Emmanuel Baccelli
		- Can reference other RFCs; anything to make the DT document shorter.

	Erik Nordmark
		- It's more subtle than that; we have the link model issue. Some  
people might think a
		  MANET is a link and so link-locals should work. That's the reason  
we want to state
                   clearly that LLs don't work the way you might think.
		- What about IPv4 link-locals?

	Emmanuel Baccelli
		- Thinks concensus was to skip those.

	Mark Townsley
		- Can we sum it up and have nods: Link locals may be configured,  
warning text from Erik N.
	        on scope issues, not used for routing.

	Teco Boot
		- Some protocols MUST have link local addresses. There are three  
experimental MANET extensions
		  for OSPF out there. Some important players are working on this.  
Cannot ignore this.
		- We should continue working on ULA and global addresses. Why this  
urge to prohibit link-
		  locals?

	Suresh Krishnan
		- Agree with Erik Nordmark, looks like link local address, but isn't  
really. It's more
		  like "interface-local". You cannot use it as a source address for  
an RS or an NS. You
		  don't even know if it is unique.

	Teco Boot
		- Link local only for single hop information, like for example  
resolving Layer 2 addresses
		  of nodes in range. All multi-hop stuff done with ULAs or globals.
		- How to do DAD is "solution space", however don't see much  
difference in uniqueness detection
		  etc.  between link-locals and globals. Either we find some  
mechanism or we accept that there
		  will be a very small chance to have duplicate addresses.

	Thomas Clausen
		- Clarifying comments on OLSR etc. can handle link local addresses,  
as long as they are unique
		  within two hops away.

	Ryuji Wakikawa
		- Maybe we should just ask the WG how many people think link-locals  
are useful and whether the
		  WG should look at the use of link-locals in the DT document.

	Fred Templin
		- Observes that a use case analysis seems to be missing. We all seem  
to have this notion of what
		  a MANET is and what we use it for. But have we ever looked at  
automobiles, planes, use inside
		  a corporate enterprise network? We all may have very different  
notions of what it means to do
		  MANET networking. Haven't seen this addressed in this group yet.  
In some use cases, there's
	 	  legitimate use of link-locals.

	Thomas Narten (Jabber)
		- Arguing again on what a link local address is? Deja vu, 20 times  
over.

	Ralph Droms (Jabber)
		- Not on the audio. I thought we concluded that LL address is  
incompatible with no prefix-based
		  direct packet delivery?

	Alex Petrescu (Jabber)
		- Agrees with that. Not sure DT agrees with that.

	Ryuji Wakikawa
		- Need to agree in which direction the WG should go. Need to  
formulate some questions.

	Thomas Clausen
		- The first question is what would be more appropriate to recommend  
w.r.t. the addresses
		  needed for routing protocol operation: the use of link-locals  
versus globals or ULAs?

	Mark Townsley
		- Thought we had agreement half an hour ago that link locals  
wouldn't even exist. Then they
		  came back, but with so much warning text around them, that nobody  
in their right mind would
		  use them, Then someone said, he would use them for the routing  
protocol anyway.

	Thomas Clausen
		- Dave Thaler observed that there RFCs mandating the existence of  
link-local addresses. Erik
		  Nordmark suggested to put so much warning text around their usage,  
that nobody would. Then,
		  let us as a group decide that the addresses we care about and will  
configure are globals
		  or ULAs.

	Mark Townsley
		- Proposal: link locals exist, warning text, autoconf will work on  
configuring ULA/global
		  addresses.

CHAIRS CALL FOR CONSENSUS IN THE ROOM: shall AUTOCONF:

	- accept that link local addresses exist, but not configure those,  
warn against their properties being
	  unguaranteed and work on the configuration of ULAs or globals for  
use within the MANET

Hum is in favour of this - needs to be validated on the mailing list.

	Teco Boot
		- Don't know what the question was. Do we simply forbid the use of  
Router Advertisements in
		  MANET? - that's a clear question. RAs mandate the use of link- 
locals.

	Thomas Clausen
		- Think that is a different question than the one that was asked.

	Ryuji Wakikawa
		- If a MANET protcol needs Routing Advertisements, we can extend the  
existing router
		  neighbour discovery protocol for that; but that's a solution space  
discussion.

	Henning Rogge
		- Maybe we can just agree that we need a way to determine a mesh net- 
unique address. Maybe
		  we just need it for the virtual interfaces for some routing  
protocols; for other protocols
		  we might need it for the interface IPs. But we need a stable way  
to get these addresses.
		  Some protocols might even have contradictory requirements for the  
attributes of their
		  interface addresses, but most want at least one net-wide or  
globally unique address. Maybe
		  a unique address from some kind of pool. The routing protocols  
could specify whether they
		  run this algorithm for every interface or use link-locals to talk  
to their neighbours, while
		  using the algorithm to get virtual interface addresses or router  
IDs. We need a method to
		  autoconfigure an address that is unique over more than one hop and  
we want to get this
		  address automatically from some pool; that's something that all  
routing protocols will
		  have in common.

	Thomas Clausen
		- Are you are arguing for or against the outcome of the 'hum' we  
just had? There seemed to
		  a consensus. Are you contesting that?

	Henning Rogge
		- My problem with the proposal is that it combined several things.  
One of them is the
		  autoconfiguration of MANET-unique (or globally unique) addresses.  
In the Internet-Draft,
		  I would not like to combine this in all cases with interface  
configuration, because there
		  seem to be some routing protocols that must use link-locals.

	Emmanuel Baccelli
		- Beg to differ. Don't know any that do, not even OSPF. It just says  
you *can* use
		  link-locals.

	Teco Boot
		- Thinks it's MUST for OSPF.

	Thomas Clausen
		- The important thing is to scope the problem down so we can make  
progress.

	Ryuji Wakikawa
		- In the document we may say that link-locals exist, but with some  
warnings attached.
		  If you can live with those, you can go ahead and use them.
		- This WG will not discuss link-locals for the purpose of  
autoconfiguration.

	Fred Templin
		- It's fine to have text that says "not recommended", "should not".  
Consenting users
		  can go ahead and do it, if they know they won't get themselves  
into trouble.
		  We are not forbidding anything.
		- This comes down to use cases again. Whether globals are needed  
depends on whether
		  an application are going to be hosted on the MANET router or not.  
Some MANET routers
		  might not host any applications. Do we have the same answer for  
those types of
		  MANET routers as for MANET routers that host applications?

	Alex Petrescu (Jabber)
		- The /128 recommendation forbids link-local addresses.

	Ralph Droms (Jabber)
		- Thought we were dropping that /128 condition as conflicting with  
existing RFCs.

	Alex Petrescu (Jabber)
		- This should be made very clear.

	Christopher Dearlove
		- I thought we simply were saying, let's configure ULA/global
		  addresses, link local addresses are orthogonal to that.

	Thomas Clausen
		- That's consistent, but with the addition that if link-locals are  
generated, the
		  caveats hold that Erik N. will provide text for.
		- We have to write this down and confirm it on the mailing list.

	Thomas Narten (Jabber)
		- IMO, /128 does not conflict with existing specs. We are blurring  
and confusing
		  various issues. You can have a /128 for on-link prefixes and still  
have a
		  64-bit Interface IDs.

Next Steps:

CHAIRS CALL FOR CONSENSUS IN THE ROOM: shall AUTOCONF:
	
	- accept the DT I-D (draft-baccelli-autoconf-adhoc-addr-model-01) as  
WG document?

Hum inconclusive, did not support adopting draft-baccelli-autoconf- 
adhoc-addr-model-01 as WG
document.

Chairs request:
	- comments from those whose hum did not support the I-D, in order to
	  be able to incorporate those in the I-D and make progress

	- the DT to issue a -02, adapted taking the comments from the meeting
	  into account.

Chairs will call for consensus on such an updated document on the list.
===========================================================