>>>>> On Wed, 2 May 2001 14:18:04 +0200 (CEST),
>>>>> Erik Nordmark <[EMAIL PROTECTED]> said:
>> 2. we'd also like to allow users to use the /64 prefix on the p2p link
>> just like an ethernet (i.e. broadcast) link. That is, when P/64 is
>> assigned to the link, users can assume there might be a node P:A on
>> the other end of the link for an arbitrary interface ID 'A', which
>> might be learned from DNS, off-line communication, some other
>> discovery mechanism, or even some misconfiguration or attacks.
> Doesn't this mean that you'd like the other end of the link have more than
> one interface ID?
Yes.
> If you allow this there is a possibility that the other end uses a very
> large number of interface IDs. Do you expect the two ends to somehow
> discover (manually?) all the interface IDs?
No, at least in our current implementation. As described above, it
just sends the packet to the p2p link, assuming the other end node has
the destination address.
> Ignoring the DoS issue for a moment, there seems to be some utility
> in sending anything in the /64 (except perhaps the sender's IP addresses -
> different implementations seem to do that differently) across the pt-pt
> link since it allows the peer to have any number of interface IDs in the /64.
> *If* we want the above flexibility I don't think a simple
> sending rule can fix the DoS issue
why not? Do you mean an attack that sends a massive number of packet
that fills in the p2p link in a single direction (i.e. not looped)?
If so, that's right, but, this type of attack cannot be prevented by
NS/NA exchanges, either.
> I think we need something akin
> to sending an NS/NA pair across the link (even though that
> sounds a bit silly on a pt-pt link).
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
