Hi,
I've read draft-dhankins-softwire-tunnel-option-03 draft recently and have
several comments and questions:
1. Tunnel type
Can we assume that IPv4-over-IPv6 will be the only tunnel type used?
I think not. Therefore tunnel-type field should be added to the DS_LITE
option. One octet is enough.
2. SI hints
I think it should be possible (or even recommended) that client will send
not only OPTION_DS_LITE in ORO, but also MAY provide OPTION_DS_LITE itself
in SOLICIT, REQUEST, RENEW, etc. messages. It should contain
address of previously used SC address, provided as a hint to the DHCPv6
server. Here's scenario, where this approach could be useful:
Network Operator may have more than one SC. It is reasonable to assume
that client-to-SC assignment will not be fixed, but rather client will be
assigned to a SC (e.g. due to load-balancing).
Using knowledge about previously used SC, Network Operator may prefer to
assign this particular client to the same SC as before. There are several
benefits of such assignment. In particular, if SI was reboot, some
enc-user sessions may still be active.
3. Preference
In section 3, multihoming is mentioned. Would it be beneficial to provide
additional field in the option called Tunnel preference? Its meaning would
be similar to the one in DHCPv6's PREFERENCE option. In case when
multihoming device has several softwire offers, it would use (or favor)
the one with highest preference. The best size for this field would be 1
octet.
4. Renewal
According to Softwire Problem Statement (RFC4925), section 1.1, softwires
are generally dynamic. Shouldn't SC address be periodically renewed? This
would be useful for graceful failover to a different SC. There are several
possible solutions:
a) Include current SC address in all RENEW messages, using DS_LITE_OPTION.
(poor choice, renewal frequency depends on leased address and
prefix T1 values)
b) use Information Refresh Time Option (RFC4242) to define how often
DS_LITE option should be renewed.
c) add T1 (and possibly T2) to the DS_LITE option, with meaning similar to
T1 and T2 used in IA_NA and IA_PD options.
Another issue is related to the following question: Is softwire permanent?
Can we assume that softwire is permanent in the sense that once
established, it will be used and is valid until SI crashes or is powered
off? What about failover scenarios when SC malfunctions or reaches end of
its lifecycle? Maybe it would be useful to specify lifetime? This counter
could be reset every time DS_LITE option is renewed, exactly the same as
addresses in IA_NA option.
Size of those fields (T1,T2, lifetime) would be standard double words and
values expressed in seconds.
5. Softwire termination
Again, Softwire Problem Statement (RFC4925), Section 1.1 states that
softwires may be initiated and terminated on demand. How should SI release
its tunnel? Assuming that softwire tunnel is teared down once SI sends
Release message is not appropriate. I think the simplest approach is the
best: SI should include OPTION_DS_LITE in the RELEASE message. Server may
acknowledge this by sending DS_LITE option with address set to ::. This
could be used to notify SC that it may free its resources associated with
tunnel for this particular SI.
6. Stateless autoconfiguration
DS_LITE on its own, without address being delegated, is useless. I think
clarification should be added that this option may not be used in
stateless DHCPv6 (i.e. is not allowed in INFORMATION-REQUEST message).
7. Leasequery
There's a mechanism for querying server about provided configuration
parameters (RFC5007). Would it be useful for a server to report that
DS_LITE option was provided to the client in question? I'm not sure if
such details should be put in the draft or not.
I think that's it for now. That's my first post on IETF, so forgive me if
I was pointing out the obvious or discussing topic already covered (I've
checked list archives, but I could have missed something).
Regards,
--
Tomasz Mrugalski Dibbler - a portable DHCPv6 implementation
[email protected] http://klub.com.pl/dhcpv6/
Gdansk University of Technology
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
