Le 10/09/2010 11:30, Hesham Soliman a écrit :
On 9/09/10 4:28 PM, "Alexandru
Petrescu"<alexandru.petrescu@xxxxxxxxx> wrote:
Le 09/09/2010 08:01, Hesham Soliman a écrit :
On 9/09/10 3:54 PM, "Wassim Haddad"<wassim.haddad@xxxxxxxxxxxx>
wrote:
On Sep 8, 2010, at 7:58 AM, Alexandru Petrescu wrote:
I agree mainly with the document draft-ietf-mext-nemo-pd.
It is good and needed to dynamically assign a Mobile Network
Prefix to the NEMO-enabled Mobile Router.
However, here are a couple of missing points.
One missing point is about how will the Mobile Router
configure its default route on the home link? I thought
Prefix Delegation would bring DHCP in the picture and would
allow MR to synthesize a default route even though RAs are
absent. But I now realize that a DHCPv6-PD implementation
(and std?) does not allow a router (MR) to synthesize its
default route (neither RA does, nor DHCPv6-nonPD does).
=> I think the MR can easily act as a host on its egress
interface and configure its default/next hop router that way. Of
course the other alternative is to use routing protocols, but I
think using ND should be sufficient.
Hesham - when at home, the MR acts as a router (ip_forward==1,
join all-routers group), as such ND is insufficient to obtain the
default route - it's a Router.
When at home, and using DHCPv-PD, the MR also acquires its Home
Address with DHCPv6. If so, then it doesn't use SLAAC to
auto-configure neither a Home Address nor a default route.
In implementation it is of course possible to dynamically change MR
behaviour from Host to Router: be at home, first act as host
(fwd==0) to acquire the Home Address and default route, then set
fwd=1 and use DHCPv6-PD to acquire a prefix (but not the Home
Address) and take advantage of the default route acquired
previously as a Host. This is one way of solving the issue.
=> Exactly.
However it is not specified.
=> Who cares, specify it in your product description. The IETF
doesn't specify how to build products.
Hmm... to me it is a very IETF sensitive issue the Router vs Host. For
example, an ND spec says distinctively what a Host and what a Router
does, e.g. a Host does not respond to Router Solicitation.
In this same way a Router should dynamically be able to obtain a default
route, in addition to a Host doing so.
The products sold are neither Hosts nor Routers - they're BFRs, servers,
desktops, tablets, laptops.
If you want to solve this with protocols then use routing protocols.
Of course you need to solve the security issues when the MR moves.
But SLAAC (what you call ND) is not a routing protocol yet does deliver
a default route, only to Hosts. DHCPv6 is not a routing protocol either
but does not deliver a default route neither to Hosts nor to Routers.
(I am not clear whether the DHCPv6 spec forbids delivery of a default
route; or allows; I have to check; the implementation does not.)
I am not
sure how clean is it anyways to disregard that 'M' bit of RA
anyways.
The alternative to using routing protocols (OSPF?) to communicate a
default route to the MR - I am not sure how this could work, never
seen it in practice.
=> For a good reason! You need to work out trust across domains.
Probably...
Alex
Hesham
Alex
Hesham
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf