Dear list,
sorry to stir the hornet's nest about end-to-end flow labels, but I think
there are some security problems in them.
First, the labels are excluded from the IPSec AH, which means they cannot be
trusted. I wouldn't build a service that is based on them, unless there is
some other way to
On Wed, 22 May 2002, Pekka Savola and Hesham Soliman (ERA) wrote:
<...>
>>Actually, as a side
>> node, I think 2462 should be deprecated and replaced by
>> 3041please don't shoot!
>
>Where did I put my M16. ;-)
>
>In the meantime, you might want to check out
>draft-dupont-ipv6-rfc3041har
Sorry, that isn't the correct model.
3GPP uses a "stratified" model. The link layer from the mobiles ends in the GGSN.
There is also another link layer, between the SGSN and the GGSN, but that is in the
lower stratum that is invisible to the mobiles. Always think about the mobile-GGSN
link as
> Is there support in this WG for making route optimization a MUST in all IPv6 hosts ?
>The ball is really in this WG's court. This is really a "do you really want
>ubiquitous end to end functionality or not?" question
I'm not sure if that rule could be enforced. If a node keeps on sending to h
Catchin up with mail...
But first, let me remind that the original text is raw. In security analysis you first
try to find all holes, then try to plug them, and only finally estimate how real the
remaining danger is. My text is still in the first phase, where paranoia is cranked up
to maximum.
...but how about mobility?
The SGSN isn't an anchor point. It may change at any moment, when the mobile does an
SGSN handover to another Routing Area. The new SGSN doesn't have a clue about what
mcast groups the mobile has joined somewhere else.
The old SGSN might inform the new one about the
Charlie,
sorry to trip a player in the same team, but there is a certain satisfaction not
unlike playing chess against a Grand Master and not losing on the first move...
> -Original Message-
> From: Perkins Charles (IPRG)
<...>
> Here are some facts:
>
> A. A mobile device transmittin
Dear list,
this issue is taking much time and ammunition, and it's mostly wasted. We know that
the decision between MUST and SHOULD will be made in the IESG, not here. It all boils
down to interpreting the words of RFC2119.
The make some progress, I'd like to suggest a work plan.
Step 1: someo
> -Original Message-
> From: ext Erik Nordmark [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 04, 2002 6:29 PM
> To: [EMAIL PROTECTED]
> Subject: DNS discovery thoughts
>
>
>
> I've been thinking about the DNS discovery, as well as the larger
> "service discovery with no 3rd party de