headers
Pekka Savola | 1 Nov 2006 10:42
Picon

Re: Re: Last Call: 'An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)' to Experimental RFC (draft-laganier-ipv6-khi)

Tailing down the Cc: a bit..

On Mon, 30 Oct 2006, Jari Arkko wrote:
> We are last calling this document for the second time, for
> two reasons. The first reason is to make sure that the
> last call has been circulated widely enough in the
> community.

I believe a document such as this is needed, though the allocation 
could be made from some other block; I don't have strong opinions on 
that.

At least Geoff asked whether these need to be drawn from the IPv6 
unicast block.  I'd like to better understand what would be the 
alternatives. Presumably this might refer to a different prefix such 
as ::/16. That might be better because that way it would be clearer 
that the prefixes are not meant to be routable as they would be more 
easily distinguished as special.  I'd suspect that at some point 
implementations or operators filter out most of ::/16 which might ease 
the leakage issues.

Others already commented about undefined 'temporary' allocation part.

A few comments,

In section 1.1:

 In practice, allocation of a separate
   prefix for ORCHIDs seems to suffice, making them compatible with IPv6
   addresses at the upper layers while simultaneously making it trivial
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Townsley | 1 Nov 2006 16:18
Picon
Favicon

int-area office hour


Jari and I will be holding a one hour "open office" from 1900-2000 
Sunday (location TBA). We are sorry to not have more hours this time - a 
joint IAB/IESG meeting conflicts with the afternoon hours we 
traditionally hold.

Thanks, and see you in San Diego.

- Mark
Permalink | Reply | 3 comments |
headers
Alper Yegin | 1 Nov 2006 20:39

RE: int-area office hour


Mark,

Can we reserve first 20 min for PANA WG? (Sorry, this 33% allocation may
look greedy, but hey, this is a mere 60min for the whole area :-)

Alper

> -----Original Message-----
> From: Mark Townsley [mailto:townsley <at> cisco.com]
> Sent: Wednesday, November 01, 2006 5:19 PM
> To: int-area <at> ietf.org
> Subject: [Int-area] int-area office hour
> 
> 
> Jari and I will be holding a one hour "open office" from 1900-2000
> Sunday (location TBA). We are sorry to not have more hours this time - a
> joint IAB/IESG meeting conflicts with the afternoon hours we
> traditionally hold.
> 
> Thanks, and see you in San Diego.
> 
> - Mark
> 
> 
> _______________________________________________
> Int-area mailing list
> Int-area <at> lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/int-area
(Continue reading)

Permalink | Reply | 1 comment |
headers
Templin, Fred L | 3 Nov 2006 01:09
Picon
Favicon

Multilink subnet issues and proxy/relay DAD

The question of proxy/relay DAD for multilink networks that
comprise shared links has come up on the NETLMM and Autoconf
mailing lists. Proxy/relay DAD is a mechanism whereby NS(DAD)
messages are relayed to the link on which a node with a
colliding address resides, with the colliding node's NA(DAD)
being relayed back to the link on which the soliciting node
resides. (The Target Link Layer Address Option in the relayed
NA(DAD) must not be changed by the relays to ensure proper
SEND operation in this process.)

James Kempf has twice indicated that there have been prior
discussions on this subject between Jari Arkko and Dave
Thaler, and that they should be consulted for further
information (see below), but several attempts to contact
them have so far produced no results.

To ensure a fair and open dialogue at IETF67, I am requesting
that Jari, Dave, James and others with firsthand information
address the following questions on the lists prior to the
meetings:

  1. What are the issues wrt proxy/relay DAD that would
     interfere with its adoption as a standard mechanism?
  2. What harmful on-link assumptions could there be for
     IPv6 Prefix Information Options that advertise a
     shared prefix with 'L=0'?
  3. Does the RFC1812 "subnet forwarding model" still apply
     to IPv6, when there are no IPv6 documents that reference
     RFC1812 normatively?
  4. What other non-obvious issues relating to multilink
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jari Arkko | 3 Nov 2006 13:26

Re: int-area office hour

Alper,
> Can we reserve first 20 min for PANA WG? (Sorry, this 33% allocation may
> look greedy, 
No problem.
> but hey, this is a mere 60min for the whole area :-)
>   
If it becomes a problem, people can catch us during
the reception. Or send mail and arrange for a meeting
during one of the breaks.

--Jari
Permalink | Reply | 0 comments |
headers
Mark Townsley | 4 Nov 2006 22:39
Picon
Favicon

I would like to serve a second term as Internet AD


There has been some discussion within the IESG and Nomcom about the best 
practice for current ADs to announce their willingness to serve another 
term or not. I've decided to email this list, and cc the current nomcom 
committee.

First, I'd like to thank everyone involved for giving me the opportunity 
to serve as Internet AD for the past year and a half.  It is truly a 
privilege to work on such a breadth of technology surrounded by so many 
industry experts. I would like to continue as Internet AD through the 
next term. Please let the nomcom know how I am doing (good or bad!). I 
am always seeking direct feedback on how I can improve as well, so 
please feel free to tell me what you think in an email, IM, phone, or in 
person this week if you are in San Diego.

Thanks,

- Mark
Permalink | Reply | 0 comments |
headers
Jari Arkko | 5 Nov 2006 07:30

Re: Multilink subnet issues and proxy/relay DAD

Hi Fred,
>   1. What are the issues wrt proxy/relay DAD that would
>      interfere with its adoption as a standard mechanism?
>   
Almost anything can be made to work, but often
the question is what works best or with least
changes. In particular, we can make proxy DAD
work, probably even with SEND. But I would
still prefer an approach that does not require
that. Also, if you need proxy DAD, does that
mean that link local multicast does not work
on the link as expected?
>   2. What harmful on-link assumptions could there be for
>      IPv6 Prefix Information Options that advertise a
>      shared prefix with 'L=0'?
>   
None that I know of.
>   3. Does the RFC1812 "subnet forwarding model" still apply
>      to IPv6, when there are no IPv6 documents that reference
>      RFC1812 normatively?
>   4. What other non-obvious issues relating to multilink
>      subnets for shared links need to be observed for NETLMM,
>      Autoconf and other contexts?
>   
I am not sure I have an answer. But let me ask you a
question about something which has been unclear
to me during the NETLMM discussion. What is the
real-world functionality that you would like to have?
Media where this is needed? Employing just one
prefix per a number of hosts? Special requirements
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mark Townsley | 6 Nov 2006 02:55
Picon
Favicon

Re: int-area office hour (w/Location)


The location is the IESG Breakout Room, Executive Center 2A.

- Mark

Mark Townsley wrote:
>
> Jari and I will be holding a one hour "open office" from 1900-2000 
> Sunday (location TBA). We are sorry to not have more hours this time - 
> a joint IAB/IESG meeting conflicts with the afternoon hours we 
> traditionally hold.
>
> Thanks, and see you in San Diego.
>
> - Mark
>
>
> _______________________________________________
> Int-area mailing list
> Int-area <at> lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/int-area
>
Permalink | Reply | 0 comments |
headers
Mark Townsley | 6 Nov 2006 20:15
Picon
Favicon

Please Review draft-cheshire-ipv4-acd-03.txt


The Internet ADs would like to solicit review for publication of this 
document as a Proposed Standard. 

Abstract

   When two hosts on the same link attempt to use the same IPv4 address
   at the same time (except in rare special cases where this has been
   arranged by prior coordination) problems ensue for one or both hosts.
   This document describes (i) a simple precaution that a host can take
   in advance to help prevent this misconfiguration from happening, and
   (ii) if this misconfiguration does occur, a simple mechanism by which
   a host can passively detect after-the-fact that it has happened, so
   that the host or administrator may respond to rectify the problem.
Permalink | Reply | 1 comment |
headers
Templin, Fred L | 6 Nov 2006 23:55
Picon
Favicon

RE: Multilink subnet issues and proxy/relay DAD

Jari - see below for follow-up: 

> Hi Fred,
>>   1. What are the issues wrt proxy/relay DAD that would
>>      interfere with its adoption as a standard mechanism?
>>   
> Almost anything can be made to work, but often
> the question is what works best or with least
> changes. In particular, we can make proxy DAD
> work, probably even with SEND. But I would
> still prefer an approach that does not require
> that. Also, if you need proxy DAD, does that
> mean that link local multicast does not work
> on the link as expected?

The question is coming from the context of what to do
about two nodes connected to different links that configure
colliding addresses and then move onto the same link at
some later point in time. It seems that a pre-service DAD
procedure like proxy/relay DAD would be preferrable to an
in-service DAD, e.g., (re)marking addresses as tentative
and (re)running DAD on link change. 

>>   2. What harmful on-link assumptions could there be for
>>      IPv6 Prefix Information Options that advertise a
>>      shared prefix with 'L=0'?
>   
> None that I know of.

OK. If a node receives a PIO with 'L=0' and then configures
(Continue reading)

Permalink | Reply | 1 comment |

Gmane