>> => 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf