> | When routers are forwarding packets, the draft doesn't
> apply since they are
> | not performing source or destination address selection.
> But when routers do
> | perform source or destination address selection, then I
> believe the draft
> | should apply. So I think it is appropri
Date:Tue, 19 Dec 2000 20:37:10 -0800
From:Richard Draves <[EMAIL PROTECTED]>
Message-ID:
<[EMAIL PROTECTED]>
| You get into these issues in more detail below, but the quick summary is
| that applications can select their own addresses (by binding to a specific
Date:Mon, 18 Dec 2000 19:01:05 +0100
From:Francis Dupont <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
|when there are multiple destination options headers in each of these two
|logical locations.
|
| => merge them???
Ugh!
| => this is th
> I have some concerns about the details, primarily because my years of
> working on a "strong host model" network layer have led me to really
> question that model. It's probably too late, for the
> protocol stack I work
> on, but I'd like to make sure it's easy for other
> implementers to use
>Are there any commercially available "IPv6 core and extensions"
>implementations in the market? If not, anyone with plans to make them
>available sometime next year?
I'm not sure wht you mean by "commercial", but there are a lot of
them, with official support (you can call up h
Are there any commercially available "IPv6 core and extensions"
implementations in the market? If not, anyone with plans to make them
available sometime next year?
Thanks,
Radha
IETF IPng Working Group Mailing List
IPng Home P
> > which in turn would prevent all communications. Also, as per RFC
> > 2401 we do not in general have the possibility to specify policies
> > for individual ICMP message types.
>
> This passed the IESG in RFC 2894 (so it must be true):
>
>
>Note that for the SPD to distinguish Router Renu
> which in turn would prevent all communications. Also, as per RFC
> 2401 we do not in general have the possibility to specify policies
> for individual ICMP message types.
This passed the IESG in RFC 2894 (so it must be true):
Note that for the SPD to distinguish Router Renumbering from oth
Stephen Kent wrote:
> > * Path MTU discovery. Consider the following case:
> >
> > (N1)(VPNGW1)(R1)(VPNGW2)-(R2)(N2)
> >
> > Assume N1 wants to send traffic to N2, part of the path
> > goes through an insecure network part, secured using
> >
Hello.
RFC 2463 section 2.4 (e) specifies that Packet Too Big can be sent as a
reply to a multicast message. Is this a source of a DoS problem? I.e.
send a message with a large MTU to a large multicast group, lie about the source
address, and flood real node with the forged source address with l
In your previous mail you wrote:
To me it would make sense to have associated data that is the index of
the security association used (is that the right term? I'm not really
up to date on IPSEC terminology).
=> I agree, the SPI is the useful key to metadata.
Would it make sense
11 matches
Mail list logo
