At Fri, 08 Apr 2005 16:52:50 -0700, Erik Nordmark wrote:
>
> 1. Add text to say "SHOULD limit packets with an anycast source to 1280
> bytes". Add note that ICMP-based tools don't work with an anycast
> source address.
Unless, of course, the application protocol in question happens to be
Fred Baker wrote:
On Apr 8, 2005, at 4:58 PM, Erik Nordmark wrote:
Applying IPsec doesn't help solve the authorization issue of who
should be allowed to receive packets sent to a particular anycast
address.
Can you tell me any address or type of address for which that is an
objective either of
On Apr 8, 2005, at 4:58 PM, Erik Nordmark wrote:
Applying IPsec doesn't help solve the authorization issue of who
should be allowed to receive packets sent to a particular anycast
address.
Can you tell me any address or type of address for which that is an
objective either of internet routing or
> >> The code below would be straightforward if the "/64" prefix were
> >> accepted by getaddrinfo.
> >>
> >> Besides, I don't think the textual representation should be defined
> to
> >> make only Basic Socket API functions straightforward. IMHO, the
> order
> >> should be logical on its own
Fred Baker wrote:
The mobility model that Joe and I discussed requires a security
association to be set up with the anycast address (IPSEC management
protocols reply with the anycast address as a source), supply a COA, and
then TCP is set up to the COA.
FWIW if you believe that routing is trustw
James Kempf wrote:
Correct. However, the v6 addressing spec prohibits the use of an
anycast address from being used as the source address in a datagram, or
being bound to an interface on a host. These two restrictions
effectively prohibit the use of anycast as a service distribution
mechanism.
Brian Haberman wrote:
o An anycast address MAY be used as the source address of an IPv6
packet.
o An anycast address MAY be assigned to an IPv6 host.
This change will allow users to operate IPv6 anycast services in the same
manner in which they do today with IPv4 anycast.
If we do th
On Fri, 8 Apr 2005, Fernando Gont wrote:
I think the ICMPv6 draft should add some words to raise awareness about
ICMP-based attacks that can be performed against transport protocols.
Any text suggestions -- just to have an idea how verbose and explicit
you're looking at; did you refer to the prop
>>
>> The code below would be straightforward if the "/64" prefix were
>> accepted by getaddrinfo.
>>
>> Besides, I don't think the textual representation should be defined
to
>> make only Basic Socket API functions straightforward. IMHO, the
order
>> should be logical on its own. The prefi
Hi, Fernando,
Looking back at the ICMPv6 draft, in the light of this, there are a number
of sanity checks that could be performed on returning error messages to
minimise security risks.
For example:
In draft-gont-tcpm-icmp-attacks-03.txt, the 'port unreachable' error is
cited as possibly being cl
The code below would be straightforward if the "/64" prefix were
accepted by getaddrinfo.
Besides, I don't think the textual representation should be defined to
make only Basic Socket API functions straightforward. IMHO, the order
should be logical on its own. The prefix is clearly more tight
Thomas Narten wrote on 04/05/2005 09:04:11 PM:
> JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
> <[EMAIL PROTECTED]> writes:
>
> > > On Fri, 1 Apr 2005 06:13:22 -0700,
> > > Kristine Adamson <[EMAIL PROTECTED]>
said:
> > > Thanks for the responses. But
if RFC3542 is not updat
(As party to the discussion which produced this new text) I don't believe
that this alters the current state of affairs significantly. If the ICMPv6
message is coming from the destination node it is (still) required by 2.2(a)
to use the destination adddress of the original message as source. Th
Folks,
I sent some comments off-list to Mukesh, and he suggested to raise them on
the list.
I think the ICMPv6 draft should add some words to raise awareness about
ICMP-based attacks that can be performed against transport protocols.
For example, the current draft suggest IPsec, or no checks at
At 10:53 09/03/2005 -0600, [EMAIL PROTECTED] wrote:
As discussed in the IPv6 WG meeting yesterday, I am planning to
replace sub-sections (b), (c) and (d) of section 2.2 in the
draft with the following text:
===
(b) If the message is a response to a message sent t
15 matches
Mail list logo
