[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPv6 broadband provisioning
On Mon, 31 Dec 2007 12:49:34 +0100
Iljitsch van Beijnum <iljitsch@muada.com> wrote:
> On 31 dec 2007, at 8:22, Mohacsi Janos wrote:
>
<snip>
> On 30 dec 2007, at 11:33, Mark Smith wrote:
>
> >> The issue that I see is that of duplicate MAC addresses. I don't see
> >> an easy way to protect against that. How does this work today in a
> >> N:1
> >> model?
>
> > The DSLAMs we use perform MAC address - wait for it - NAT, into
> > algorithmically calculated MAC addresses, in part based on line card
> > and node IDs.
>
> Which of course creates all the usual problems that NAT always
> creates: what about protocols that embed the translated addresses? In
> this case, that would be neighbor discovery.
>
Good point. That puts us between a rock and hard place. It's something
we'd want to leave enabled to avoid the effects of MAC address
collisions, accidental or intentional, but it would probably interfere
with the operation of ND/RAs and possibly DHCPv6. I might start looking
into that a bit more, and when I get back to work on Thursday, discuss
it with our DSLAM expert. We're only using that feature for PPPoE
connections at the moment, and that's obviously working, so I'd presume
PPPoE doesn't carry any MAC address info in the payload.
> > It's ugly thinking about all the FCSes that are being
> > recalculated all the time
>
> That happens in the ethernet hardware, not an issue.
>
I think it's ugly for a couple of reasons - the reason you mention
above, and also that the FCS isn't being preserved from the ultimate
source to the ultimate destination node, which creates the opportunity
for corruption to be introduced during the FCS recalculation.
Admittedly 802.1q does the same thing, so it's probably an acceptable
risk (ISL would have been better for the IEEE to adopt if the hardware
out there had been able to cope with it as the trunked or rather
tunnelled frame isn't modified).
Regards,
Mark.