=> That can work but I don't understand why you don't like the host
on egress interface behaviour. The RFC seems inconsistent on its
requirements for the egress interface at home, but it's been a long
time since I read it so I may have forgotten some of the reasons. I
think it can work and at least it will lead to a consistent
implementation.
I am not sure which RFC you mean seem inconsistent? If rfc3963 - yes,
it says MR MAY use the received RAs on the egress interface to
autoconfigure an address and form a default route. However, I think in
practice pure linux does not do it (or am I missing radvd procsys
options?). One would have to check the public NEMOv6 implementations
too. Without NEMOv6 implementation this does not work (i.e. that MAY is
interpreted as a no on pure linux). With it I don't know.
=> Ok but now you're talking about an implementation issue. 3963 allows the
router to act as a host on its egress at home. Either we change
implementations or the RFC needs to be changed. Kernel implementations need
ro change anyway to support nemov6.
I myself have forgotten many of the reasons. I think I vaguely remember
Pascal insisting of that being MR-autoconfigure an address as a MAY
because IIRC a Cisco router would autoconfigure an address and a default
route. I am not very precise on this remembering.
=> I also think what he suggested makes sense. Which means the MR would act
the same way at home or on a visited link when it comes to listening to RAs.
So it adds little argument to the need for dhc extensions.
If you mean RFC4861 then I think it is consistent andgood it has this
distinction between Host and Router (Router doesn't autoconfigure a
default route, etc.).
=> I was talking about 3963. 4861 is fine in this respect.
Hesham
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf