Dave Thaler wrote:
>
> Antonio Querubin writes:
> > If it is how about just defining mapped multicast addresses already?
> [...]
> >|80 bits | 16 | 32 bits|
> >+--+--+
> >|.
At 4:46 AM +0100 3/19/02, Francis Dupont wrote:
> In your previous mail you wrote:
>
> > A full implementation of IPv6 includes implementation of the
> > following extension headers:
>
>=> this wording is unfortunate: what is a partial implementation
>of IPv6?
It is an incomplete imple
At 12:29 PM +0900 3/21/02, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
wrote:
>Perhaps we have two choices:
>
>1. treat :: as global
>2. does (explicitly) not define the scope type (level) of ::
>
>Even the choice 2 will make the document clear, and it will not cause
>a problem in a pr
Title: RE: Allocating a bit in the RFC2437 Interface Identifier
> In which case, I violently agree with Keith. We've already
> overloaded IP addresses with two functions - locator and
> identifier.
I would rather see the WG focus on the value of using a bit to specify whether the address is
Title: RE: New WG flow label draft (-01)
This looks very good and informative. Thank You.
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 20, 2002 7:09 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: New WG flow label d
> On Thu, 21 Mar 2002 08:17:06 +0900 (JST),
> Keiichi SHIMA <[EMAIL PROTECTED]> said:
>> 1. revise the mobility section to clarify issues about using
>> site-local addresses with mobile IPv6:
>>
>> => I disagree with your solution because it takes more than a few line
>> to describe it
> On Wed, 20 Mar 2002 11:19:40 -0800,
> "Richard Draves" <[EMAIL PROTECTED]> said:
> Sorry I wasn't reading correctly - obviously you were discussing the
> unspecified address not the loopback address!!
Okay.
> It's not clear to me that the unspecified address has a well-defined
> scop
> On Wed, 20 Mar 2002 19:44:07 +0100 (CET),
> Erik Nordmark <[EMAIL PROTECTED]> said:
>> + to deal with such issues, we'll need an ability for mobile nodes
>> to tell whether a correspondent node or the home agent is in the
>> same site as the mobile node. However, there is currently no
> On Wed, 20 Mar 2002 17:53:15 +0100,
> Francis Dupont <[EMAIL PROTECTED]> said:
>Ahh, a nasty person might then ask: why are we burdening all other
>addresses with this
> %.
>when they don't need it, and the only place where it would be needed
>(that MIB ex
JINMEI Tatuya / $B?@L@C#:H(B wrote:
>
> > On Mon, 18 Mar 2002 12:57:26 -0500,
> > Brian Haberman <[EMAIL PROTECTED]> said:
>
> > I agree the text should be updated. To address your points 'c'
> > and 'd', it should be pointed out that 2462 was written so that there
> > was no dep
Hi,
We had some face-to-face time on Tuesday, which resulted into a new revision of the
flow label draft. The presentation on Thursday will be based on this.
Jarno
<>
IPv6 Working Group J. Rajahalme
INTERNET-DRAFT
> A security hint is needed. Please read the "bidding down" notes
> to see why. For reference, here are the URLs again:
>
> http://playground.sun.com/mobile-ip/WG-archive/frm05357.html
> http://www.piuha.net/~jarkko/publications/mipv6/Bidding_down.txt
I'd have to have more background to be sur
In your previous mail you wrote:
Are you saying that if we use a bi-directional tunneling, the off-site
MN can comunicate with the CN that is in the home-site of the MN?
=> exactly, this works as soon as the IPv6 stack supports multi-site
as it should.
If so, I disagree. Consider
Hi,
From: Francis Dupont <[EMAIL PROTECTED]>
>
>1. revise the mobility section to clarify issues about using
> site-local addresses with mobile IPv6:
>
> => I disagree with your solution because it takes more than a few line
> to describe it (:-).
> IMHO site-local addresses in a mobi
Brian,
> In which case, I violently agree with Keith. We've already
> overloaded IP addresses with two functions - locator and
> identifier. We've been rebuffing various suggestions for
> yet more overloading for years (the porno bit for example) and
> this is in the same category - not the righ
> > yet more overloading for years (the porno bit for example) and
> Hmm.. interesting piece of history. Any references? :-)
one data point
I was asked by some folk (who claimed to be technical) in the lobby
of the court building where I was testifying in the communications decency
act case to
On Wed, 20 Mar 2002, Brian E Carpenter wrote:
[snip]
> overloaded IP addresses with two functions - locator and
> identifier. We've been rebuffing various suggestions for
> yet more overloading for years (the porno bit for example) and
[snip]
Hmm.. interesting piece of history. Any references? :
Brian E Carpenter wrote:
> I must say I don't understand the reference to RFC2437...
> presumably you mean 2374, which will be obsoleted anyway.
2437 was a mistake, pardon my poor sleep deprived brain.
The subject line should now have the right reference.
> In which case, I violently agree with
Keith Moore wrote:
>
> > there has emerged a need to encode functional, security related
> > semantics into IP addresses
>
> I strongly disagree.
>
> there has been a longstanding need to encode functional security
> related semantics into IP packets.
>
> but the address is entirely the wrong
Title: RE: poposed changes to the scoping architecture draft
Yes,
I agree, this probably is the wrong ID to make the note in. I'll see if such a note is in the current revision of the MIPv6 draft. That should be sufficient.
> -Original Message-
> From: Francis Dupont [mailto:[EMAI
> there has emerged a need to encode functional, security related
> semantics into IP addresses
I strongly disagree.
there has been a longstanding need to encode functional security
related semantics into IP packets.
but the address is entirely the wrong place for these.
Keith
Can you change the subject: RFC 2437 is PKCS #1 ???
[EMAIL PROTECTED]
PS: IMHO we should serialize reservation and use, so I'll read
your message just after Erik presentation+discussion tomorrow!
IETF IPng Working Group Mailing
Jinmei
JINMEI Tatuya wrote:
>
> As described in the 03 draft, one possibility is a kind of MIB entry
> which only specifies a particular zone (of a particular scope type).
> Such a possibility is one of the reasons to adopt this type of format
> since the 03 version.
>
What would this zone m
Actually, having a single RTM supporting IPv4, IPv6 (global-scoped
or otherwise), and any other protocol requires some intelligence on
the part of the routing protocol. In my prototype of IPv6 scoped
routing, I maintained a single RTM without a problem. However, I had
to implement a mechanism th
Sorry I wasn't reading correctly - obviously you were discussing the
unspecified address not the loopback address!!
It's not clear to me that the unspecified address has a well-defined
scope level...
> -Original Message-
> From: Richard Draves [mailto:[EMAIL PROTECTED]]
> Sent: Wednesda
As discussed at the mobile-ip WG meeting on Tuesday morning, in length
at the mobile-ip mailing list, and in some length at the this mailing
list, there has emerged a need to encode functional, security related
semantics into IP addresses. The purpose of this short note is to try
to describe the
On Wed, 20 Mar 2002, Erik Nordmark wrote:
> I don't have a problem removing compatible addresses from the addressing
> architecture, but I also don't think it is required.
> Once RFC2893bis blows it away its gone whether or not the addressing
> architecture contains the defintion for compatible ad
>> Btw. what is the scope level of address "::"? = 0?
>
>Hmm, good question. I personally think "::" can be treated as a
>global scope with regards to the scope architecture,
> because it does
>not cause ambiguity about the "zone". And, in fact, our current
>implementat
> Thursday is the last chance to phase out IPv4 compatible addresses
> and automatic tunnels. I propose to add this point to the discussion
> about RFC 2373 revision.
The plan in ngtrans has been to remove this by creating RFC1933ter = RFC2893bis
without these pieces.
I don't have a problem remo
> + to deal with such issues, we'll need an ability for mobile nodes
> to tell whether a correspondent node or the home agent is in the
> same site as the mobile node. However, there is currently no
> standard way to implement the ability.
I agree that the issues here needs to be p
On Wed, Mar 20, 2002 at 11:03:21AM +0100, Ignatios Souvatzis wrote:
> On Wed, Mar 20, 2002 at 10:45:04AM +0100, Ignatios Souvatzis wrote:
> > On Wed, Mar 20, 2002 at 10:36:30AM +0530, Murugan KAT wrote:
> >
> > > Let us think of a single RTM having for both V4 and V6.
> > > But to what extent th
In your previous mail you wrote:
Ahh, a nasty person might then ask: why are we burdening all other
addresses with this
%.
when they don't need it, and the only place where it would be needed
(that MIB example), is not actually using address at all!
=> as my goal is
In your previous mail you wrote:
> On Tue, 19 Mar 2002 22:53:22 -0600,
> "Glenn Morrow" <[EMAIL PROTECTED]> said:
> Maybe I'm just paranoid but does anyone think that it should be recommended
> that integrity protection of some sort be done when a mobile uses a site
>
In your previous mail you wrote:
> Btw. what is the scope level of address "::"? = 0?
Hmm, good question. I personally think "::" can be treated as a
global scope with regards to the scope architecture, because it does
not cause ambiguity about the "zone". And, in fact, our cu
On Wed, Mar 20, 2002 at 10:45:04AM +0100, Ignatios Souvatzis wrote:
> On Wed, Mar 20, 2002 at 10:36:30AM +0530, Murugan KAT wrote:
>
> > Let us think of a single RTM having for both V4 and V6.
> > But to what extent this is valid from routing stacks.? Will it be valid to
> > propogate V4 routing
On Wed, Mar 20, 2002 at 10:36:30AM +0530, Murugan KAT wrote:
> Let us think of a single RTM having for both V4 and V6.
> But to what extent this is valid from routing stacks.? Will it be valid to
> propogate V4 routing info. also to V6 domain.? Obviously the other way is
> not valid?
In a multi
> From: JINMEI Tatuya / $B?@L@C#:H(B <[EMAIL PROTECTED]>
> As described in the 03 draft, one possibility is a kind of MIB entry
> which only specifies a particular zone (of a particular scope type).
> Such a possibility is one of the reasons to adopt this type of format
> since the 03 version.
37 matches
Mail list logo
