Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: IPv6/IPv6 threat Comparison Paper available for review

  • From: Tony Hain
  • Date: Thu May 13 17:55:21 2004

Iljitsch van Beijnum wrote:
> On 11-mei-04, at 3:13, Darrin Miller wrote:
> >
> Ok, some comments:
> ...
> - Fragmentation
> You can't drop non-last fragments that are smaller than 1280 bytes as a
> host may fragment a packet into equal size parts rather than a big and
> a small part. Testing if you can get away with it makes no sense as new
> implementations come on the market all the time. If you want to do this
> you can probably do it at around ~600 bytes for non-last fragments as
> there is no legitimate need to fragment packets that are already 1280
> bytes or smaller, so if this is done anyway it's probably for reasons
> you don't like.

Technically you are correct, but if the firewalls are deployed first those
later systems will have to conform to what the network allows. 

> - Smurf
> I don't think you mention that in IPv6, there are no mechanisms that
> allow an incoming unicast packet to be turned into a broadcast or
> multicast packet, and as such, smurf-like attacks are impossible.

It can be done on-link by a zombie, but that is not the strict definition of
a remote smurf attack.

> - Tunneling
> Why only filter outbound tunneling?
> - Use of multiple addresses
> You say that RFC 3041 helps against scanning. It doesn't, as hosts also
> keep their EUI-64 derived addresses. In IPv6 it is required to support
> having multiple addresses on an interface.

There is no requirement for an end system to use the EUI-64 suffix with a
global prefix. It is a perfectly reasonable scenario for the system to have
a policy that says only use 3041 with global prefixes, and EUI-64 for the
FE80:: & FC00:: prefixes. The only real issue is how the end system derives
a consistent value for anything it registers in DDNS. Even then it can be
based on an apparently random set of bits as long as they don't change and
create churn in DNS. 


Discussion Communities

About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home

Merit Network, Inc.