At Tue, 17 Jul 2007 16:35:33 -0400,
James Carlson <[EMAIL PROTECTED]> wrote:
> Generating NS and processing NA drives the state machine associated
> with neighbor cache entries.
>
> > other ND functions, of course they should be supported.
>
> I don't see how you get there at all. You need to b
>> > I don't know of any cases where omitting ND for IPv6 addresses makes
>> > much sense.
>>
>> OK, so at least we've clarified that we're in disagreement. I don't see
>> support in the specs for doing address resolution on links without
>> link-layer addresses. what would the purpose be in doing
Ole Troan writes:
> > I don't know of any cases where omitting ND for IPv6 addresses makes
> > much sense.
>
> OK, so at least we've clarified that we're in disagreement. I don't see
> support in the specs for doing address resolution on links without
> link-layer addresses. what would the purpose
>> I think it's easy to see the disagreement just comparing the responses
>> from Ole and James.
>>
>> Ole says:
>> > I don't see the point of doing address resolution on links without
>> > addresses.
>
> If you've actually got links with no addresses at all, then I agree.
> That seems odd, thou
Markku Savela writes:
>
> > Yes, I expect address resolution to be done on PPP links, just as is
> > described in 2461. I expect it to be done _regardless_ of the
> > underlying link technology.
>
> If link like PPP does not have link layer addresses, there is no point
> in doing "address resolu
> Yes, I expect address resolution to be done on PPP links, just as is
> described in 2461. I expect it to be done _regardless_ of the
> underlying link technology.
If link like PPP does not have link layer addresses, there is no point
in doing "address resolution". Nobody should require impleme
Ole Troan writes:
> > I think it's easy to see the disagreement just comparing the responses
> > from Ole and James.
> >
> > Ole says:
> >> I don't see the point of doing address resolution on links without
> >> addresses.
> >
> > James says:
> >> IPV6CP (RFC 2472) negotiates
> >> only interface
Dave Thaler writes:
> I think it's easy to see the disagreement just comparing the responses
> from Ole and James.
>
> Ole says:
> > I don't see the point of doing address resolution on links without
> > addresses.
If you've actually got links with no addresses at all, then I agree.
That seems o
Ole Troan wrote:
[...]
> >> point-to-point - Neighbor Discovery handles such links just
like
> >> multicast links. (Multicast can be trivially
> >> provided on point to point links, and
interfaces
> >> can be assigned link-local ad
> I think it's easy to see the disagreement just comparing the responses
> from Ole and James.
>
> Ole says:
>> I don't see the point of doing address resolution on links without
>> addresses.
>
> James says:
>> IPV6CP (RFC 2472) negotiates
>> only interface identifiers, and not addresses, and ND
I think it's easy to see the disagreement just comparing the responses
from Ole and James.
Ole says:
> I don't see the point of doing address resolution on links without
> addresses.
James says:
> IPV6CP (RFC 2472) negotiates
> only interface identifiers, and not addresses, and ND
> (2461) says
> Came across this thread...
>
> http://www1.ietf.org/mail-archive/web/ipv6/current/msg02314.html
>
>
>
> However, in looking at draft-ietf-ipv6-over-ppp-v2-03, it seems that
> this issue was never addressed.
>
>
>
> Is this intentional? Was there ever an agreement that ND should or
> should n
Dave Thaler writes:
> Is this intentional? Was there ever an agreement that ND should or
> should not be done on PPP links?
I'm surprised that it's a question at all. IPV6CP (RFC 2472)
negotiates only interface identifiers, and not addresses, and ND
(2461) says that Neighbor Discovery is suppose
Came across this thread...
http://www1.ietf.org/mail-archive/web/ipv6/current/msg02314.html
However, in looking at draft-ietf-ipv6-over-ppp-v2-03, it seems that
this issue was never addressed.
Is this intentional? Was there ever an agreement that ND should or
should not be done on PPP lin
14 matches
Mail list logo