Soliman, Hesham wrote:
FWIW I don't have a problem with ndproxy being published while incompatible
with SeND. There are other examples of completely insecure experimental
RFCs, e.g. Fast handoffs. It's essential to make the document consistent though.
what is being discussed is incompatibility betw
>
> In your previous mail you wrote:
>
>But the implications should IMHO be explored at some length first
>(maybe write an I-D?). Changing MAC addresses is going to cause
more
>disruption on the roaming host in case of false positives, i.e.,
the
>laptop thinks it moved but actua
I know NDproxy is a WG item, but I think this problem space deserves a
discussion on its own. Although it has implications on IPv6 ND, I think
stretching subnets beyond links mean further than that. And there is
already another proposal contending for a similar problem space,
Rbridging. Before we
> Alain Durand wrote:
> ...
> > The argument that NDproxy will only be used in a certain
> environments
> > where SEND is not needed is clearly bogus, The IETF is not about
> > defining standards for special cases but for the whole Internet.
>
> I disagree as a matter of principle. It i
In your previous mail you wrote:
But the implications should IMHO be explored at some length first
(maybe write an I-D?). Changing MAC addresses is going to cause more
disruption on the roaming host in case of false positives, i.e., the
laptop thinks it moved but actually didn't,
On Thu, 27 Jan 2005, Christian Huitema wrote:
On Thu, 27 Jan 2005, Nick 'Sharkey' Moore wrote:
Ethernet-derived addresses are indeed also an issue, but they're
hypothetically unique ... so we're back to estimating the
inestimable ... are they less likely to collide than 3041 because
of this suppose
Christian,
> Rhetorical question: how long will it take before computers
> systematically configure a new MAC address each time they reboot, or
> each time they roam to a new network?
Some l2's / networks are doing this already.
John
-
