Subject: [Softwires] A few draft-dhankins-softwire-tunnel-option-03 comments

From: Tomasz Mrugalski <[email-masked]>
Date: Mon, 29 Jun 2009 01:55:05 +0200 (CEST)

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-masked]    http://klub.com.pl/dhcpv6/
Gdansk University of Technology

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 29 Jun 2009 17:18:03 +0800

>From the title of this draft, it only serves the dual-stack lite scenario.
For 
support generic tunnel scenarios, we have recently proposed a new draft
draft-guo-softwire-sc-discovery
http://tools.ietf.org/html/draft-guo-softwire-sc-discovery-00 
to softwire WG. It proposes a general softwire (tunnel) concentrator 
discovery mechanism. It is generic to server different kinds of
tunnel/softwire
concentrator auto discover scenarios includes the scenario of 
draft-dhankins-softwire-tunnel-option.

Regards,

Sheng

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Tomasz Mrugalski
> Sent: Monday, June 29, 2009 7:55 AM
> To: [email-masked]
> Subject: [Softwires] A few 
> draft-dhankins-softwire-tunnel-option-03 comments
> 
> 
> Hi,
> I've read draft-dhankins-softwire-tunnel-option-03 draft 
> recently and have several comments and questions:
> 
> 1. Tunnel type
> 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:
> 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.
> 
> 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,
> -- 
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires