Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
Dear authors,
Thank you for your hard work! I think we are trying to move forward.
I have some comments on the provisioning method.
In the section 4.4 that there is a new sub-option OPTION_MAP_BIND. It is the
sub-option of OPTION_MAP (OPTION_SW) used to convey an IPv4 address.
Considering OPTION_MAP (OPTION_SW) is a DHCPv6 option, it is a little confusing
that we are going to use DHCPv6 for IPv4 resources allocation. IMHO, this
should be the decision of DHC WG, which hasn't published the outcome of this
issue.
Is it possible that we make this part clearer?
Best Regards,
Qi
On 2012-12-6, at 下午2:35, mohamed.boucad...@orange.com
mohamed.boucad...@orange.com wrote:
Hi Tina,
Many thanks for the comments. Some clarifications below:
* DS-Lite is included in the scope for the reasons detailed in the draft (see
Section 1.1):
(2) Simplify solution migration paths: Define a unified CPE behavior
which allows for smooth migration between the different modes
and
(4) Re-usability: Maximize the re-use of existing functional blocks
including Tunnel Endpoint, port restricted NAPT44, Forwarding
behavior, etc.
* Public 4over6 is already included in the draft:
(2) Binding approach (e.g., Lightweight 4over6 (Lw4o6)
[I-D.cui-softwire-b4-translated-ds-lite],
[I-D.ietf-softwire-public-4over6] or MAP 1:1
[I-D.ietf-softwire-map] ): Requires a single per-subscriber
state (or a few) to be maintained in the Service Provider's
network.
* I agree with you the title should be updated to reflect the scope of the
draft. The proposed scope is IPv4 service continuity over IPv6 mechanisms.
Cheers,
Med
De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la
part de Tina TSOU
Envoyé : mercredi 5 décembre 2012 19:34
À : ian.far...@telekom.de
Cc : softwires@ietf.org
Objet : Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
Dear Med, Ian and Suresh,
Great job! Draft-bfmk is written very well to reach consensus.
Two small comments are below.
1. I’m not sure whether it is appropriate to put DS-Lite case into the
document, since in DS-Lite case the CPE is only the tunnel end point without
NAT, which is basically different with lw4over6/MAP. But if the objective of
this document is to define an unified CPE for all the 4over6 mechanisms,
other mechanisms like public 4over6 should also be included in the document.
My understanding may be wrong.
2. The title says “unified softwire CPE”, but in softwire, there are
many other transition technologies, e.g., 6rd. To be specific, maybe 4over6
CPE is more appropriate.
Thank you,
Tina
On Dec 4, 2012, at 9:53 AM, ian.far...@telekom.de ian.far...@telekom.de
wrote:
Hi Ole,
Answers inline.
Cheers,
Ian
-Original Message-
From: Ole Trøan [mailto:otr...@employees.org]
Sent: Montag, 3. Dezember 2012 10:06
To: Farrer, Ian
Cc: simon.perrea...@viagenie.ca; softwires@ietf.org
Subject: Re: [Softwires] Unified Softwire CPE:
draft-bfmk-softwire-unified-cpe
Ian,
Whichever state is selected, NAT is certainly fundamental to how the state
will operate and so we tried to weave it into the functional description.
I'm not sure that provisioned NAT info enough to be able to use to
unambiguously define with operating 'mode' (for want of a better word) to
use.
One of the reasons for the use of state in the draft is try and define the
operating modes with as little overlap as possible (it's not 100%, but
there's only 1 exception at the moment for binding mode and MAP1:1). From
this, then it is easier to align the specific solution names to the state
characteristics.
I don't think you should try to define modes such that the map (no pun
intended) into the specific solution names.
shouldn't the purpose of a unified CPE, be for the CPE not to have to care
about the different deployment modes on the head end?
Ian: But a MAP CPE does have to care about what is on the tunnel head end as
it could be another mesh client, or it could be the BR. It uses a different
mapping rule type for each, so it is aware of the capabilities of the head
end.
But, with what you've suggested, there is more overlap, i.e. both 24 have
NAT functions that are supported by two different mechanisms.
However, what you've said does raise the following point:
The way that state is described in the draft at the moment is actually
taken from a concentrator perspective. This could be taken to be almost the
inverse of the amount of state that is required from the CPEs perspective
(i.e. if all of the state is in the providers network (DS-Lite), then the
CPE doesn't need it. If the providers network has less state
('per-customer', 'stateless'), then the CPE needs to have more - i.e.
dynamic state table for NAT, configuration for local IPv4/port set, MAPing
rules etc.
Would
Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
Qiong, from MAP's perspective it doesn't matter if it is a /64 on the WAN or a /56 delegated prefix. any prefix can have EA bits. [Qiong] In theory, right. But I think it still have several issues here: 1) The /64 WAN prefix or a /56 delegated prefix does not have a flag saying hey, I'm the one with EA bits. Then, how can a CPE choose which prefix to extract the EA bits ? Or do you need another configuration flag to indicate which prefix to embed to EA bits? from the draft: A MAP node finds its Basic Mapping Rule by doing a longest match between the End-user IPv6 prefix and the Rule IPv6 prefix in the Mapping Rules table. The rule is then used for IPv4 prefix, address or shared address assignment. cheers, Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
Ian,
Whichever state is selected, NAT is certainly fundamental to how the state
will operate and so we tried to weave it into the functional description. I'm
not sure that provisioned NAT info enough to be able to use to unambiguously
define with operating 'mode' (for want of a better word) to use.
One of the reasons for the use of state in the draft is try and define the
operating modes with as little overlap as possible (it's not 100%, but
there's only 1 exception at the moment for binding mode and MAP1:1). From
this, then it is easier to align the specific solution names to the state
characteristics.
I don't think you should try to define modes such that the map (no pun
intended) into the specific solution names.
shouldn't the purpose of a unified CPE, be for the CPE not to have to care
about the different deployment modes on the head end?
But, with what you've suggested, there is more overlap, i.e. both 24 have
NAT functions that are supported by two different mechanisms.
However, what you've said does raise the following point:
The way that state is described in the draft at the moment is actually taken
from a concentrator perspective. This could be taken to be almost the inverse
of the amount of state that is required from the CPEs perspective (i.e. if
all of the state is in the providers network (DS-Lite), then the CPE doesn't
need it. If the providers network has less state ('per-customer',
'stateless'), then the CPE needs to have more - i.e. dynamic state table for
NAT, configuration for local IPv4/port set, MAPing rules etc.
Would describing the different states more from the CPE's perspective make
this clearer?
that would certainly help. although I don't think state is the defining
characteristic.
cheers,
Ole
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
Hi Ole, As a background, the usual modes supported by a CPE are: IPv4-only, Dual-stack. A natural mode to be added to the list is IPv6-only ... but this mode is not sufficient to reflect whether IPv4 service continuity features are enabled in the CPE or not. This draft focuses on this service: i.e., IPv4 service continuity when only an IPv6 prefix is configured to the CPE. Now for the items you listed below, I do not see them as modes but as a set of actions to be enforced based on some trigger(s). The combination of the actions listed below will result in a mode. The CPE will need some trigger(s) to decide which modules are to be mounted (e.g., NAT, port restriction, etc.) and how some configuration will be enforced (e.g., IPv6@ of the local IPv4-in-IPv6 tunnel, IPv4 address, etc.). Several cases are to be considered: (1) a CPE is complied to support only one mode: no issue here. (2) a CPE supports several modes but only one mode is explicitly configured: once a mode is enabled, the behaviour of the CPE is similar to (1) (3) the CPE supports several modes but no mode is explicitly enabled: the CPE will need additional triggers to decide which mode to activate (e.g., If only a Remote IPv4-in-IPv6 Tunnel Endpoint is configured, this means the stateful mode must be enabled). A mode is defined as a set of actions (mount a module, configuration actions). The list of actions you provided needs to be captured somehow in the draft. I will double check the text and see whether any item is missing in -00. Thanks. Cheers, Med -Message d'origine- De : Ole Trøan [mailto:otr...@employees.org] Envoyé : vendredi 30 novembre 2012 20:36 À : BOUCADAIR Mohamed OLNC/OLN Cc : Simon Perreault; softwires@ietf.org Objet : Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe Med, et al, Med: The rationale we adopted in this draft is as follows: * there are three major flavors: full stateful, full stateless, and binding mode * all these modes can support assigning a full or a shared IPv4 address now you got me thinking, are these really the right modes from a CPE perspective? let me try to explain, with my CPE implementor hat on, what modes would make sense? - NAT placement. do I need a NAT on the CPE or not? (no NAT no IPv4 address == DS-lite) - full IPv4 address assigned. I can assign the IPv4 address to the tunnel endpoint interface, and use that address for local applications, and as the outbound address of the NAT (mechanisms: MAP, Public 4over6) - IPv4 prefix assigned: I need to disable the CPE NAT, and use the assigned IPv4 prefix as my LAN side DHCPv4 pool (mechanism: MAP) - Shared IPv4 address. I must enable a local NAT, I cannot assign the IPv4 address on the WAN interface, but only use it for the outbound side of the NAT. then there might be a sub-modes for tunnel endpoint determination i.e. how to determine an IPv6 tunnel end point address given an IPv4 destination address and port. 1) algorithmic (MAP) 2) configured (Public 4over6, LW46, DS-lite) and a sub-mode for IPv4 address configuration: 1) As native IPv4 (Public4over6, LW46) 2) Embedded Address (MAP) 3) None DS-lite does this make sense? cheers, Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
On 12/3/12 4:55 AM, mohamed.boucad...@orange.com mohamed.boucad...@orange.com wrote: Hi Ole, As a background, the usual modes supported by a CPE are: IPv4-only, Dual-stack. A natural mode to be added to the list is IPv6-only ... but this mode is not sufficient to reflect whether IPv4 service continuity features are enabled in the CPE or not. This draft focuses on this service: i.e., IPv4 service continuity when only an IPv6 prefix is configured to the CPE. Now for the items you listed below, I do not see them as modes but as a set of actions to be enforced based on some trigger(s). The combination of the actions listed below will result in a mode. The CPE will need some trigger(s) to decide which modules are to be mounted (e.g., NAT, port restriction, etc.) and how some configuration will be enforced (e.g., IPv6@ of the local IPv4-in-IPv6 tunnel, IPv4 address, etc.). Several cases are to be considered: (1) a CPE is complied to support only one mode: no issue here. (2) a CPE supports several modes but only one mode is explicitly configured: once a mode is enabled, the behaviour of the CPE is similar to (1) (3) the CPE supports several modes but no mode is explicitly enabled: the CPE will need additional triggers to decide which mode to activate (e.g., If only a Remote IPv4-in-IPv6 Tunnel Endpoint is configured, this means the stateful mode must be enabled). A mode is defined as a set of actions (mount a module, configuration actions). To make this list complete, #4 should be CPE supports several modes and several modes are configured. Thanks Senthil The list of actions you provided needs to be captured somehow in the draft. I will double check the text and see whether any item is missing in -00. Thanks. Cheers, Med -Message d'origine- De : Ole Trøan [mailto:otr...@employees.org] Envoyé : vendredi 30 novembre 2012 20:36 À : BOUCADAIR Mohamed OLNC/OLN Cc : Simon Perreault; softwires@ietf.org Objet : Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe Med, et al, Med: The rationale we adopted in this draft is as follows: * there are three major flavors: full stateful, full stateless, and binding mode * all these modes can support assigning a full or a shared IPv4 address now you got me thinking, are these really the right modes from a CPE perspective? let me try to explain, with my CPE implementor hat on, what modes would make sense? - NAT placement. do I need a NAT on the CPE or not? (no NAT no IPv4 address == DS-lite) - full IPv4 address assigned. I can assign the IPv4 address to the tunnel endpoint interface, and use that address for local applications, and as the outbound address of the NAT (mechanisms: MAP, Public 4over6) - IPv4 prefix assigned: I need to disable the CPE NAT, and use the assigned IPv4 prefix as my LAN side DHCPv4 pool (mechanism: MAP) - Shared IPv4 address. I must enable a local NAT, I cannot assign the IPv4 address on the WAN interface, but only use it for the outbound side of the NAT. then there might be a sub-modes for tunnel endpoint determination i.e. how to determine an IPv6 tunnel end point address given an IPv4 destination address and port. 1) algorithmic (MAP) 2) configured (Public 4over6, LW46, DS-lite) and a sub-mode for IPv4 address configuration: 1) As native IPv4 (Public4over6, LW46) 2) Embedded Address (MAP) 3) None DS-lite does this make sense? cheers, Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
Ole,
On 2012-12-3, at 下午5:06, Ole Trøan wrote:
Ian,
Whichever state is selected, NAT is certainly fundamental to how the state
will operate and so we tried to weave it into the functional description.
I'm not sure that provisioned NAT info enough to be able to use to
unambiguously define with operating 'mode' (for want of a better word) to
use.
One of the reasons for the use of state in the draft is try and define the
operating modes with as little overlap as possible (it's not 100%, but
there's only 1 exception at the moment for binding mode and MAP1:1). From
this, then it is easier to align the specific solution names to the state
characteristics.
I don't think you should try to define modes such that the map (no pun
intended) into the specific solution names.
shouldn't the purpose of a unified CPE, be for the CPE not to have to care
about the different deployment modes on the head end?
[Qi] I think the modes are functional modes rather than deployment modes.
CPE has different functional characteristics under different modes and it has
to know what behavior it should perform under different mode.
But, with what you've suggested, there is more overlap, i.e. both 24 have
NAT functions that are supported by two different mechanisms.
However, what you've said does raise the following point:
The way that state is described in the draft at the moment is actually taken
from a concentrator perspective. This could be taken to be almost the
inverse of the amount of state that is required from the CPEs perspective
(i.e. if all of the state is in the providers network (DS-Lite), then the
CPE doesn't need it. If the providers network has less state
('per-customer', 'stateless'), then the CPE needs to have more - i.e.
dynamic state table for NAT, configuration for local IPv4/port set, MAPing
rules etc.
Would describing the different states more from the CPE's perspective make
this clearer?
that would certainly help. although I don't think state is the defining
characteristic.
[Qi] IMHO, using state as the defining characteristic, the CPE can determine
which module to mount and which functionality to perform.
Best Regards,
Qi
cheers,
Ole
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
Hi Ole,
Whichever state is selected, NAT is certainly fundamental to how the state will
operate and so we tried to weave it into the functional description. I'm not
sure that provisioned NAT info enough to be able to use to unambiguously define
with operating 'mode' (for want of a better word) to use.
One of the reasons for the use of state in the draft is try and define the
operating modes with as little overlap as possible (it's not 100%, but there's
only 1 exception at the moment for binding mode and MAP1:1). From this, then it
is easier to align the specific solution names to the state characteristics.
But, with what you've suggested, there is more overlap, i.e. both 24 have NAT
functions that are supported by two different mechanisms.
However, what you've said does raise the following point:
The way that state is described in the draft at the moment is actually taken
from a concentrator perspective. This could be taken to be almost the inverse
of the amount of state that is required from the CPEs perspective (i.e. if all
of the state is in the providers network (DS-Lite), then the CPE doesn't need
it. If the providers network has less state ('per-customer', 'stateless'), then
the CPE needs to have more - i.e. dynamic state table for NAT, configuration
for local IPv4/port set, MAPing rules etc.
Would describing the different states more from the CPE's perspective make this
clearer?
Cheers,
Ian
-Original Message-
From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf
Of Ole Trøan
Sent: Samstag, 1. Dezember 2012 09:48
To: Simon Perreault
Cc: softwires@ietf.org
Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
Simon,
Med: The rationale we adopted in this draft is as follows:
* there are three major flavors: full stateful, full stateless, and
binding mode
* all these modes can support assigning a full or a shared IPv4
address
now you got me thinking, are these really the right modes from a CPE
perspective?
let me try to explain, with my CPE implementor hat on, what modes would
make sense?
- NAT placement. do I need a NAT on the CPE or not?
(no NAT no IPv4 address == DS-lite)
- full IPv4 address assigned.
I can assign the IPv4 address to the tunnel endpoint interface, and use
that address for
local applications, and as the outbound address of the NAT
(mechanisms: MAP, Public 4over6)
- IPv4 prefix assigned:
I need to disable the CPE NAT, and use the assigned IPv4 prefix as my LAN
side DHCPv4 pool
(mechanism: MAP)
- Shared IPv4 address.
I must enable a local NAT, I cannot assign the IPv4 address on the WAN
interface, but only use it
for the outbound side of the NAT.
Interesting... But note that even just implementing MAP alone would generate
three of these implementation modes. I would still like to see this list
added to an implementation considerations section. Stuff like you can't
assign a partial address to a tunnel interface may not be obvious to
implementers.
then there might be a sub-modes for tunnel endpoint determination i.e. how
to determine an IPv6 tunnel end point address given an IPv4 destination
address and port.
1) algorithmic (MAP)
2) configured (Public 4over6, LW46, DS-lite)
and a sub-mode for IPv4 address configuration:
1) As native IPv4
(Public4over6, LW46)
2) Embedded Address
(MAP)
3) None
DS-lite
does this make sense?
Totally appropriate for an implementation considerations section IMHO.
I'm suggesting to replace the current drafts state*, binding modes with these
modes.
cheers,
Ole
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
Qiong, [Qiong] and a sub-mode for source IPv6 address determiniation, how to determine the encapsulated IPv6 source address. 1) algorithmic, LAN prefix + embedded IPv4 address/PSID in Interface Identifier (MAP) 2) WAN IPv6 address (DS-Lite, LW46, Public 4over6) Right ? MAP could also create its tunnel endpoint address from the WAN prefix (not address). so you'd have, for CPE tunnel end point address: 1) arbitrary IPv6 address (DS-lite) 2) WAN IPv6 address (DS-lite, LW46, Public 4over6) 3) Algorithmic End-user IPv6 prefix + Well known interface-id (MAP) cheers, Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
Simon, Med: The rationale we adopted in this draft is as follows: * there are three major flavors: full stateful, full stateless, and binding mode * all these modes can support assigning a full or a shared IPv4 address now you got me thinking, are these really the right modes from a CPE perspective? let me try to explain, with my CPE implementor hat on, what modes would make sense? - NAT placement. do I need a NAT on the CPE or not? (no NAT no IPv4 address == DS-lite) - full IPv4 address assigned. I can assign the IPv4 address to the tunnel endpoint interface, and use that address for local applications, and as the outbound address of the NAT (mechanisms: MAP, Public 4over6) - IPv4 prefix assigned: I need to disable the CPE NAT, and use the assigned IPv4 prefix as my LAN side DHCPv4 pool (mechanism: MAP) - Shared IPv4 address. I must enable a local NAT, I cannot assign the IPv4 address on the WAN interface, but only use it for the outbound side of the NAT. Interesting... But note that even just implementing MAP alone would generate three of these implementation modes. I would still like to see this list added to an implementation considerations section. Stuff like you can't assign a partial address to a tunnel interface may not be obvious to implementers. then there might be a sub-modes for tunnel endpoint determination i.e. how to determine an IPv6 tunnel end point address given an IPv4 destination address and port. 1) algorithmic (MAP) 2) configured (Public 4over6, LW46, DS-lite) and a sub-mode for IPv4 address configuration: 1) As native IPv4 (Public4over6, LW46) 2) Embedded Address (MAP) 3) None DS-lite does this make sense? Totally appropriate for an implementation considerations section IMHO. I'm suggesting to replace the current drafts state*, binding modes with these modes. cheers, Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
Ole, On Sat, Dec 1, 2012 at 4:44 PM, Ole Trøan otr...@employees.org wrote: Qiong, [Qiong] and a sub-mode for source IPv6 address determiniation, how to determine the encapsulated IPv6 source address. 1) algorithmic, LAN prefix + embedded IPv4 address/PSID in Interface Identifier (MAP) 2) WAN IPv6 address (DS-Lite, LW46, Public 4over6) Right ? MAP could also create its tunnel endpoint address from the WAN prefix (not address). so you'd have, for CPE tunnel end point address: Thanks for clarification. But if MAP uses the WAN prefix as its tunnel endpoint address, does BR need to keep all the records for CPEs (because the CPE's WAN prefix might be arbitary) ? Or do you mean the CPE's WAN prefix will be embedded with EA bits ? Would you please explain it a bit more ? 1) arbitrary IPv6 address (DS-lite) Why it is arbitary ? Is it the source address of the tunnel endpoint ? Thanks Qiong 2) WAN IPv6 address (DS-lite, LW46, Public 4over6) 3) Algorithmic End-user IPv6 prefix + Well known interface-id (MAP) cheers, Ole -- == Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * === ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
Qiong, [...] MAP could also create its tunnel endpoint address from the WAN prefix (not address). so you'd have, for CPE tunnel end point address: Thanks for clarification. But if MAP uses the WAN prefix as its tunnel endpoint address, does BR need to keep all the records for CPEs (because the CPE's WAN prefix might be arbitary) ? Or do you mean the CPE's WAN prefix will be embedded with EA bits ? Would you please explain it a bit more ? from MAP's perspective it doesn't matter if it is a /64 on the WAN or a /56 delegated prefix. any prefix can have EA bits. 1) arbitrary IPv6 address (DS-lite) Why it is arbitary ? Is it the source address of the tunnel endpoint ? in DS-lite the tunnel concentrator learns the tunnel endpoint address when the NAT bindings are created. so the CPE is free to pick whatever IPv6 address it has. this is different from Public 4over6 and LW46 where the address has to be configured on both ends. cheers, Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
Dear Maoke, Thank you for the review and comments. Please see inline. Cheers, Med De : Maoke [mailto:fib...@gmail.com] Envoyé : vendredi 30 novembre 2012 03:31 À : Suresh Krishnan Cc : BOUCADAIR Mohamed OLNC/OLN; draft-cui-softwire-b4-translated-ds-lite; draft-ietf-softwire-...@tools.ietf.org; draft-ietf-softwire-public-4ov...@tools.ietf.org; softwires@ietf.org; draft-ietf-softwire-map-d...@tools.ietf.org Objet : Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe thanks Med for the initialization of the work! i noticed that: 1. MAP is working in the context of prefix delegation and therefore the LAN side IPv6 addresses (prefix) is involved in the mapping between the IPv4 and IPv6, while lw4over6 applies the WAN IPv6 address directly. when a unified CPE is made, the logic of the address assignment to interfaces should also consider this difference in the behaviour. [Med] I'm not sure I understand your point. Could you please clarify further the difference between the stateless and binding mode and what you think it should be added to bullet (2.3.2) of Section 3.4? Thanks. 2. is the deployment of difference modes able to be overlapped? current section 4.4 implies the answer is yes. i agree. but is it the best behaviour to select one mode at the device-wise according to a certain preferences? my question is: when the CPE receives multiple rules/parameter-sets from different sources of provisioning, can it store and use these pieces of information to adapt packets for corresponding mode of service, i.e., applying a proper mode on demand and session-specific? [Med] The current text says: o For a given network attachment, only one mode MUST be activated. o The CPE MAY be configured by a user or via remote device management means (e.g., DHCP, TR-069). o A network which supports one or several modes MUST return valid configuration data allowing requesting devices to unambiguously select a single mode to use for attachment. Does this text answer your questions? If not, what you think is needed to be added? Thanks. 3. related to 2, how can we keep the CPE/BR CPE/AFTR consistency? 4. fragmentation issue is common to all modes and it is also needed to be clarified/unified for the unified CPE. [Med] Fully agree. We preferred to focus first on the unified logic. If the WG accepts the proposed direction, then the document should be updated to cover items common to all modes. only my 2 cents, identifying the problems that i expect this draft to cover. - maoke 2012/11/29 Suresh Krishnan suresh.krish...@ericsson.commailto:suresh.krish...@ericsson.com Thanks Med. This is a highly exploratory draft to be used as a strawman to determine if an unified CPE is even possible. Please comment on it so that we can determine if proceeding in this path is worthwhile. Also, if you are interested in being an editor of this draft and are not currently working on any of the current solution drafts please contact the chairs. Thanks Suresh - Original Message - From: mohamed.boucad...@orange.commailto:mohamed.boucad...@orange.com mohamed.boucad...@orange.commailto:mohamed.boucad...@orange.com To: draft-ietf-softwire-...@tools.ietf.orgmailto:draft-ietf-softwire-...@tools.ietf.org draft-ietf-softwire-...@tools.ietf.orgmailto:draft-ietf-softwire-...@tools.ietf.org, draft-ietf-softwire-map-d...@tools.ietf.orgmailto:draft-ietf-softwire-map-d...@tools.ietf.org draft-ietf-softwire-map-d...@tools.ietf.orgmailto:draft-ietf-softwire-map-d...@tools.ietf.org, draft-ietf-softwire-public-4ov...@tools.ietf.orgmailto:draft-ietf-softwire-public-4ov...@tools.ietf.org draft-ietf-softwire-public-4ov...@tools.ietf.orgmailto:draft-ietf-softwire-public-4ov...@tools.ietf.org, draft-cui-softwire-b4-translated-ds-lite draft-cui-softwire-b4-translated-ds-l...@tools.ietf.orgmailto:draft-cui-softwire-b4-translated-ds-l...@tools.ietf.org, Reinaldo Penno (repenno) repe...@cisco.commailto:repe...@cisco.com, softwires@ietf.orgmailto:softwires@ietf.org softwires@ietf.orgmailto:softwires@ietf.org Sent: 11/29/2012 5:16 AM Subject: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe Dear all, As agreed in Atlanta, we prepared an I-D describing a proposed approach for the unified CPE. We hope this version is a good starting point to have fruitful discussion. Your comments, suggestions and contributions are more than welcome. Cheers, Med -Message d'origine- De : i-d-announce-boun...@ietf.orgmailto:i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.orgmailto:i-d-announce-boun...@ietf.org] De la part de internet-dra...@ietf.orgmailto:internet-dra...@ietf.org Envoyé : jeudi 29 novembre 2012 10:57 À : i-d-annou...@ietf.orgmailto:i-d-annou...@ietf.org Objet : I-D Action: draft-bfmk-softwire-unified-cpe-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories
Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
dear Med, thanks for the response. please see inline. 2012/11/30 mohamed.boucad...@orange.com ** Dear Maoke, Thank you for the review and comments. Please see inline. Cheers, Med -- *De :* Maoke [mailto:fib...@gmail.com] *Envoyé :* vendredi 30 novembre 2012 03:31 *À :* Suresh Krishnan *Cc :* BOUCADAIR Mohamed OLNC/OLN; draft-cui-softwire-b4-translated-ds-lite; draft-ietf-softwire-...@tools.ietf.org; draft-ietf-softwire-public-4ov...@tools.ietf.org; softwires@ietf.org; draft-ietf-softwire-map-d...@tools.ietf.org *Objet :* Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe thanks Med for the initialization of the work! i noticed that: 1. MAP is working in the context of prefix delegation and therefore the LAN side IPv6 addresses (prefix) is involved in the mapping between the IPv4 and IPv6, while lw4over6 applies the WAN IPv6 address directly. when a unified CPE is made, the logic of the address assignment to interfaces should also consider this difference in the behaviour. [Med] I'm not sure I understand your point. Could you please clarify further the difference between the stateless and binding mode and what you think it should be added to bullet (2.3.2) of Section 3.4? Thanks. [maoke] i a little doubt the binding mode is a proper way to unify the MAP 1:1 and lw4over6. because MAP 1:1 is still working in the model of delegation while lw4over6 applies the WAN IPv6 address for the encapsulation. what if the CPE has a delegated prefix at LAN and an address at WAN simultaneously? which address is used for the source address of the tunnel in the binding mode? is the CPE choice fits the reality at the AFTR/BR? to my understanding, the behaviour of MAP 1:1 is identical with any MAP but different from lw4over6 to some extent. 2. is the deployment of difference modes able to be overlapped? current section 4.4 implies the answer is yes. i agree. but is it the best behaviour to select one mode at the device-wise according to a certain preferences? my question is: when the CPE receives multiple rules/parameter-sets from different sources of provisioning, can it store and use these pieces of information to adapt packets for corresponding mode of service, i.e., applying a proper mode on demand and session-specific? [Med] The current text says: o For a given network attachment, only one mode MUST be activated. [maoke ] why only ONE mode MUST be activated? [maoke] we noticed a fact that a domain of softwire, at least MAP, can be different from the domain in the sense of autonomous system, because the model of prefix delegation is totally independent of the deployment of the softwire. this feature makes the softwire domain able to spread over different AS. therefore it is possible that a CPE is involved in a AS's lw4over6 domain and meanwhile also involved in a inter-AS MAP domain. administration of the lw4over6 domain and that of the MAP domain are surely independent to each other but they impact the CPE simultaneously -- it could be treated as a typical case of softwire multi-homing. and we expect the CPE gets the benefits from the multi-homing: policy-based path selection, load-balance, fault-tolerance, etc. o The CPE MAY be configured by a user or via remote device management means (e.g., DHCP, TR-069). o A network which supports one or several modes MUST return valid configuration data allowing requesting devices to unambiguously select a single mode to use for attachment. Does this text answer your questions? If not, what you think is needed to be added? Thanks. 3. related to 2, how can we keep the CPE/BR CPE/AFTR consistency? 4. fragmentation issue is common to all modes and it is also needed to be clarified/unified for the unified CPE. [Med] Fully agree. We preferred to focus first on the unified logic. If the WG accepts the proposed direction, then the document should be updated to cover items common to all modes. thanks, - maoke P.S. i will be in a 3-nights2-days trip since tonight so any further discussion will be responded in the beginning of next week. sorry in advance for the delay. only my 2 cents, identifying the problems that i expect this draft to cover. - maoke 2012/11/29 Suresh Krishnan suresh.krish...@ericsson.com Thanks Med. This is a highly exploratory draft to be used as a strawman to determine if an unified CPE is even possible. Please comment on it so that we can determine if proceeding in this path is worthwhile. Also, if you are interested in being an editor of this draft and are not currently working on any of the current solution drafts please contact the chairs. Thanks Suresh - Original Message - From: mohamed.boucad...@orange.com mohamed.boucad...@orange.com To: draft-ietf-softwire-...@tools.ietf.org draft-ietf-softwire-...@tools.ietf.org, draft-ietf-softwire-map-d...@tools.ietf.org draft-ietf
Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
Hi, While thanking the authors for their attempt, I need to provide some high level feedback first on key issues: The rationale section 1.1 states co-existance as the goal - this appears to imply some entirely different solutions for which co-existance is needed, and here are two points: A) I can agree that DS.-lite is an entirely different solution, but I firmly believe that it is entirely outside the agreed scope which was a unified solution CPE spec in the context of MAP and Lw4o6. Thus, I would recommend that ds.-lite be dropped from this draft as it bears no influence on unifying MAP and Lw4o6, nor does it bear anything on the already defined and shipped ds.-lite solution. Work on such themes of multiple solutions coexisting is what the v6ops CPE draft is covering and I would place ds.-lite coexistence there. B) I disagree that co-existance between Lw4o6 and MAP is a goal; a unified functional CPE spec for NAT44-less core relays accessed via IPv6 is. As such, describing modes as in solution modes is not conductive to that and a solution term neutral functional breakdown is essential and IMO possible (further explained below). This will only make the spec better and simpler for implementers. In Section 3 the draft coin a new term/class of solution called Binding approach. This effectively refers to configuration state which *all* solutions need, and is not helpful in providing anything but more verbiage. Removing this classification from all of the text is recommended. Further in section 3 the draft lists different functional elements, and it is here that major changes are needed. For a unified solution a functional breakdown in a solution neutral text is essential. IMO A unified CE has the following basic functionalities, which I propose to be added to the text in place of the existing one: - IPv4 NAT whose address and port restrictions are configurable - an IPv6 transport whose source and destination transport address are deterministically derived/configurable - an IPv4 routing capability (also configurable) In example terms, consider a CPE configured with IPv4 address, restricted Port range X and IPv6 source address Y and transport address Z. There is no difference in these parameters between Lw4o6 and MAP, and it shows the essence of what we need to get at. One can comment further on the details of the draft, but getting the basic functional breakdown is essential (example above) before we get into that. The only thing different between the solutions are not the basic functionalities but rather how this functionality is configured. Regards, Woj.. On 29/11/2012 11:16, mohamed.boucad...@orange.com mohamed.boucad...@orange.com wrote: Dear all, As agreed in Atlanta, we prepared an I-D describing a proposed approach for the unified CPE. We hope this version is a good starting point to have fruitful discussion. Your comments, suggestions and contributions are more than welcome. Cheers, Med -Message d'origine- De : i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.org] De la part de internet-dra...@ietf.org Envoyé : jeudi 29 novembre 2012 10:57 À : i-d-annou...@ietf.org Objet : I-D Action: draft-bfmk-softwire-unified-cpe-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Unified Softwire CPE Author(s) : Mohamed Boucadair Ian Farrer Suresh Krishnan Filename: draft-bfmk-softwire-unified-cpe-00.txt Pages : 12 Date: 2012-11-29 Abstract: Transporting IPv4 packets over IPv6 is a common solution to the problem of IPv4 service continuity over IPv6-only provider networks. A number of differing functional approaches have been developed for this, each having their own specific characteristics. As these approaches share a similar functional architecture and use the same data plane mechanisms, this memo describes a specification whereby a single CPE can interwork with all of the standardized and proposed approaches to providing encapsulated IPv4 in IPv6 services. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-bfmk-softwire-unified-cpe There's also a htmlized version available at: http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ I-D-Announce mailing list i-d-annou...@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
Hi Woj, Many thanks for the comments. Please see inline. Cheers, Med -Message d'origine- De : Wojciech Dec (wdec) [mailto:w...@cisco.com] Envoyé : vendredi 30 novembre 2012 11:42 À : BOUCADAIR Mohamed OLNC/OLN; draft-ietf-softwire-...@tools.ietf.org; draft-ietf-softwire-map-d...@tools.ietf.org; draft-ietf-softwire-public-4ov...@tools.ietf.org; draft-cui-softwire-b4-translated-ds-lite; Reinaldo Penno (repenno); softwires@ietf.org Objet : Re: Unified Softwire CPE: draft-bfmk-softwire-unified-cpe Hi, While thanking the authors for their attempt, I need to provide some high level feedback first on key issues: The rationale section 1.1 states co-existance as the goal - this appears to imply some entirely different solutions for which co-existance is needed, and here are two points: A) I can agree that DS.-lite is an entirely different solution, but I firmly believe that it is entirely outside the agreed scope which was a unified solution CPE spec in the context of MAP and Lw4o6. Thus, I would recommend that ds.-lite be dropped from this draft as it bears no influence on unifying MAP and Lw4o6, nor does it bear anything on the already defined and shipped ds.-lite solution. Work on such themes of multiple solutions coexisting is what the v6ops CPE draft is covering and I would place ds.-lite coexistence there. Med: We included DS-Lite in the scope because of the following: * Several WG participants are concerned with optimizing the code and re-using existing modules. * Some DS-Lite components are shared with A+P solution: e.g., tunnel endpoint * A+P may be seen as an exit strategy of the CGN: optimisation migration path and required changes in the CPEs need to be taken into account. B) I disagree that co-existance between Lw4o6 and MAP is a goal; Med: MAP1:1 and lw4o6 are presented in the draft as soltuions for the binding mode. a unified functional CPE spec for NAT44-less core relays accessed via IPv6 is. As such, describing modes as in solution modes is not conductive to that and a solution term neutral functional breakdown is essential and IMO possible (further explained below). This will only make the spec better and simpler for implementers. Med: This is what we tried to do in http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-00#section-4.3. In Section 3 the draft coin a new term/class of solution called Binding approach. Med: FYI, this is not a new term: please refer to http://tools.ietf.org/html/rfc6346#section-4.4. This effectively refers to configuration state which *all* solutions need, and is not helpful in providing anything but more verbiage. Removing this classification from all of the text is recommended. Med: IMHO this is the core of the discussion between MAP and Lw4o6 teams. Having a neutral terminology and a full understand of what this is about is IMHO important to converge. Further in section 3 the draft lists different functional elements, and it is here that major changes are needed. Med: Section 3 is to be seen as a reminder for the solution flavors we have on the table. This section can be moved to an appendix. I would expect we focus our discussion on Section 4. For a unified solution a functional breakdown in a solution neutral text is essential. Med: We really tried to adopt a neutral terminology in Section 4. Suggestions are welcome on how to enhance that section. IMO A unified CE has the following basic functionalities, which I propose to be added to the text in place of the existing one: Med: Could you please point me which text you are referring to? Thanks. - IPv4 NAT whose address and port restrictions are configurable - an IPv6 transport whose source and destination transport address are deterministically derived/configurable - an IPv4 routing capability (also configurable) Med: What does that mean? In example terms, consider a CPE configured with IPv4 address, restricted Port range X and IPv6 source address Y and transport address Z. There is no difference in these parameters between Lw4o6 and MAP, and it shows the essence of what we need to get at. Med: Isn't that what is captured in Table 3: Supported Features ? +--++-+-+ | Functional | IPv4-in-IPv6 | Port-restricted | Port-restricted | | Element | tunnel | IPv4 | NAT44 | | |endpoint| | | +--++-+-+ | B4 | Yes | N/A |No | +--++-+-+ | lwB4 | Yes | Yes | Optional| +--++-+-+ | MAP-E CE | Yes | Yes | Optional|
Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
Hi Med., On 30/11/2012 12:10, mohamed.boucad...@orange.com mohamed.boucad...@orange.com wrote: Hi Woj, Many thanks for the comments. Please see inline. Cheers, Med -Message d'origine- De : Wojciech Dec (wdec) [mailto:w...@cisco.com] Envoyé : vendredi 30 novembre 2012 11:42 À : BOUCADAIR Mohamed OLNC/OLN; draft-ietf-softwire-...@tools.ietf.org; draft-ietf-softwire-map-d...@tools.ietf.org; draft-ietf-softwire-public-4ov...@tools.ietf.org; draft-cui-softwire-b4-translated-ds-lite; Reinaldo Penno (repenno); softwires@ietf.org Objet : Re: Unified Softwire CPE: draft-bfmk-softwire-unified-cpe Hi, While thanking the authors for their attempt, I need to provide some high level feedback first on key issues: The rationale section 1.1 states co-existance as the goal - this appears to imply some entirely different solutions for which co-existance is needed, and here are two points: A) I can agree that DS.-lite is an entirely different solution, but I firmly believe that it is entirely outside the agreed scope which was a unified solution CPE spec in the context of MAP and Lw4o6. Thus, I would recommend that ds.-lite be dropped from this draft as it bears no influence on unifying MAP and Lw4o6, nor does it bear anything on the already defined and shipped ds.-lite solution. Work on such themes of multiple solutions coexisting is what the v6ops CPE draft is covering and I would place ds.-lite coexistence there. Med: We included DS-Lite in the scope because of the following: * Several WG participants are concerned with optimizing the code and re-using existing modules. This is an implementation reason. Should we include in this draft anything that re-uses IPinIP tunneling, which is presumably the module in question? * Some DS-Lite components are shared with A+P solution: e.g., tunnel endpoint The tunnel endpoint is an address, and again, this hardly justfies ds.-lite inclusion Most notably the functionality of the regular DS.-lite AFTR is orthogonal to the working of the CPE. * A+P may be seen as an exit strategy of the CGN: optimisation migration path and required changes in the CPEs need to be taken into account. These topics are fine subject for some CGN-exit draft, rather then muddying up this one. B) I disagree that co-existance between Lw4o6 and MAP is a goal; Med: MAP1:1 and lw4o6 are presented in the draft as soltuions for the binding mode. And the binding mode and duplicate descriptions should be removed IMO. a unified functional CPE spec for NAT44-less core relays accessed via IPv6 is. As such, describing modes as in solution modes is not conductive to that and a solution term neutral functional breakdown is essential and IMO possible (further explained below). This will only make the spec better and simpler for implementers. Med: This is what we tried to do in http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-00#section-4.3. In Section 3 the draft coin a new term/class of solution called Binding approach. Med: FYI, this is not a new term: please refer to http://tools.ietf.org/html/rfc6346#section-4.4. The point is that this is effectively configuration state, and calling it new terms is not changing things. This effectively refers to configuration state which *all* solutions need, and is not helpful in providing anything but more verbiage. Removing this classification from all of the text is recommended. Med: IMHO this is the core of the discussion between MAP and Lw4o6 teams. Having a neutral terminology and a full understand of what this is about is IMHO important to converge. You don't need any terminology like binding mode, especially in the CPE spec since the CPE side doesn't care about what configuration is on the concentrator. It only cares about its own configuration and there is no difference Further in section 3 the draft lists different functional elements, and it is here that major changes are needed. Med: Section 3 is to be seen as a reminder for the solution flavors we have on the table. This section can be moved to an appendix. I would expect we focus our discussion on Section 4. For a unified solution a functional breakdown in a solution neutral text is essential. Med: We really tried to adopt a neutral terminology in Section 4. Suggestions are welcome on how to enhance that section. Suggestion is to can the myriad of tables and agree to the break down the basic functionality. This then allows us to focus on how it is expected to be configured (the mechanism of configuration) and using what external means (eg IP addresses, DHCP option). IMO A unified CE has the following basic functionalities, which I propose to be added to the text in place of the existing one: Med: Could you please point me which text you are referring to? Thanks. Section 3.1 - IPv4 NAT whose address and port restrictions are configurable - an IPv6 transport whose source and destination transport address are deterministically derived/configurable - an
Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
Le 2012-11-29 11:16, mohamed.boucad...@orange.com a écrit : As agreed in Atlanta, we prepared an I-D describing a proposed approach for the unified CPE. We hope this version is a good starting point to have fruitful discussion. Your comments, suggestions and contributions are more than welcome. Here are some: - First, I think this is very positive. I like what I'm reading. - Didn't we also consider public 4o6 as one mode? Any reason why it was left out? - Is public 4o6 the minor change to lw4o6 that section 4.1 hints at? - In section 3.2. Required Provisoning Information, I believe it would be possible and beneficial to specify only what each mode requires *in addition* to what the previous mode already provides. e.g. - DS-Lite requires the remote tunnel endpoint address. - In addition to that, lw4o6 requires the CPE's IPv4 address and port set. - In addition to that, MAP requires mesh routes. So each mode's provisioning parameters would be a superset of the previous one. (DS-Lite lw4o6 MAP) One we have this kind of hierarchical provisioning, we can define CPE behaviour in the same way. For example, MAP behaviour would be: 1. Do exactly what a lw4o6 CPE does. 2. In addition to 1, also send and receive packets directly to and from other CPEs according to the provisioned mesh routes. (I will refrain from commenting on section 4.4 until we have the higher-level design figured out.) Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
Hi Simon, Please see inline. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Simon Perreault Envoyé : vendredi 30 novembre 2012 13:59 À : softwires@ietf.org Objet : Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe Le 2012-11-29 11:16, mohamed.boucad...@orange.com a écrit : As agreed in Atlanta, we prepared an I-D describing a proposed approach for the unified CPE. We hope this version is a good starting point to have fruitful discussion. Your comments, suggestions and contributions are more than welcome. Here are some: - First, I think this is very positive. I like what I'm reading. Med: Thanks. - Didn't we also consider public 4o6 as one mode? Any reason why it was left out? - Is public 4o6 the minor change to lw4o6 that section 4.1 hints at? Med: The rationale we adopted in this draft is as follows: * there are three major flavors: full stateful, full stateless, and binding mode * all these modes can support assigning a full or a shared IPv4 address As such Public4over6 is classified as part of binding mode (see Section 3) (2) Binding approach (e.g., Lightweight 4over6 (Lw4o6) [I-D.cui-softwire-b4-translated-ds-lite], [I-D.ietf-softwire-public-4over6] or MAP 1:1 [I-D.ietf-softwire-map] ): Requires a single per-subscriber state (or a few) to be maintained in the Service Provider's network. - In section 3.2. Required Provisoning Information, I believe it would be possible and beneficial to specify only what each mode requires *in addition* to what the previous mode already provides. e.g. - DS-Lite requires the remote tunnel endpoint address. - In addition to that, lw4o6 requires the CPE's IPv4 address and port set. - In addition to that, MAP requires mesh routes. So each mode's provisioning parameters would be a superset of the previous one. (DS-Lite lw4o6 MAP) Med: The current text of Section 3.2 says: +-+-+ |Mode | Provisioning Information| +-+-+ | DS-Lite | Remote IPv4-in-IPv6 Tunnel Endpoint | | Lw4o6 | Remote IPv4-in-IPv6 Tunnel Endpoint | | | IPv4 Address| | | Port Set| | MAP-E | Mapping Rules | | | MAP Domain Parameters | +-+-+ Table 4: Provisioning Information Note: MAP Mapping Rules are translated into the following configuration parameters: Set of Remote IPv4-in-IPv6 Tunnel Endpoints, IPv4 Address and Port Set. Can you please explicit the change you want to see appear in that text? Thanks. One we have this kind of hierarchical provisioning, we can define CPE behaviour in the same way. For example, MAP behaviour would be: 1. Do exactly what a lw4o6 CPE does. 2. In addition to 1, also send and receive packets directly to and from other CPEs according to the provisioned mesh routes. Med: Do you think this is different from the approach adopted in Section 4.3? (I will refrain from commenting on section 4.4 until we have the higher-level design figured out.) Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
Re-, Please see inline/ Cheers, Med -Message d'origine- De : Wojciech Dec (wdec) [mailto:w...@cisco.com] Envoyé : vendredi 30 novembre 2012 13:21 À : BOUCADAIR Mohamed OLNC/OLN; draft-ietf-softwire-...@tools.ietf.org; draft-ietf-softwire-map-d...@tools.ietf.org; draft-ietf-softwire-public-4ov...@tools.ietf.org; draft-cui-softwire-b4-translated-ds-lite; Reinaldo Penno (repenno); softwires@ietf.org Objet : Re: Unified Softwire CPE: draft-bfmk-softwire-unified-cpe Hi Med., On 30/11/2012 12:10, mohamed.boucad...@orange.com mohamed.boucad...@orange.com wrote: -Message d'origine- De : Wojciech Dec (wdec) [mailto:w...@cisco.com] Envoyé : vendredi 30 novembre 2012 11:42 À : BOUCADAIR Mohamed OLNC/OLN; draft-ietf-softwire-...@tools.ietf.org; draft-ietf-softwire-map-d...@tools.ietf.org; draft-ietf-softwire-public-4ov...@tools.ietf.org; draft-cui-softwire-b4-translated-ds-lite; Reinaldo Penno (repenno); softwires@ietf.org Objet : Re: Unified Softwire CPE: draft-bfmk-softwire-unified-cpe Hi, While thanking the authors for their attempt, I need to provide some high level feedback first on key issues: The rationale section 1.1 states co-existance as the goal - this appears to imply some entirely different solutions for which co-existance is needed, and here are two points: A) I can agree that DS.-lite is an entirely different solution, but I firmly believe that it is entirely outside the agreed scope which was a unified solution CPE spec in the context of MAP and Lw4o6. Thus, I would recommend that ds.-lite be dropped from this draft as it bears no influence on unifying MAP and Lw4o6, nor does it bear anything on the already defined and shipped ds.-lite solution. Work on such themes of multiple solutions coexisting is what the v6ops CPE draft is covering and I would place ds.-lite coexistence there. Med: We included DS-Lite in the scope because of the following: * Several WG participants are concerned with optimizing the code and re-using existing modules. This is an implementation reason. Should we include in this draft anything that re-uses IPinIP tunneling, which is presumably the module in question? * Some DS-Lite components are shared with A+P solution: e.g., tunnel endpoint The tunnel endpoint is an address, and again, this hardly justfies ds.-lite inclusion Most notably the functionality of the regular DS.-lite AFTR is orthogonal to the working of the CPE. * A+P may be seen as an exit strategy of the CGN: optimisation migration path and required changes in the CPEs need to be taken into account. These topics are fine subject for some CGN-exit draft, rather then muddying up this one. Med: It is unfortunate to specify a unified CPE and exclude DS-Lite from it. All the solutions we are discussing have the same objectives: offer IPv4 service continuity over IPv6 network. Unlike A+P related solution, * DS-Lite code is already supported by some CPEs * NAT44 code is already supported by CPEs * A standard method to provision the remote IPv4-in-IPv6 tunnel endpoint The draft provides these items as a reminder. Having this big picture view will help in assessing which modules are worth to be re-used and which functions are missing. New solutions is almost a combination of existing modules + new configuration parameters. As I said earlier, all Section 3 can be removed to an appendix. I personally preferred to have in the core text for -00 so the WG is aware of: * solution flavors * subtleties between these solutions B) I disagree that co-existance between Lw4o6 and MAP is a goal; Med: MAP1:1 and lw4o6 are presented in the draft as soltuions for the binding mode. And the binding mode and duplicate descriptions should be removed IMO. a unified functional CPE spec for NAT44-less core relays accessed via IPv6 is. As such, describing modes as in solution modes is not conductive to that and a solution term neutral functional breakdown is essential and IMO possible (further explained below). This will only make the spec better and simpler for implementers. Med: This is what we tried to do in http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-00# section-4.3. In Section 3 the draft coin a new term/class of solution called Binding approach. Med: FYI, this is not a new term: please refer to http://tools.ietf.org/html/rfc6346#section-4.4. The point is that this is effectively configuration state, and calling it new terms is not changing things. This effectively refers to configuration state which *all* solutions need, and is not helpful in providing anything but more verbiage. Removing this classification from all of the text is recommended. Med: IMHO this is the core of the discussion between MAP and Lw4o6 teams. Having a neutral terminology and a full understand of what this is about is IMHO important to converge. You don't need any terminology like binding mode, especially in the CPE spec since the CPE side doesn't care about what
Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
Hi Simon, One answer in line (I think Med covered off the rest) Cheers, Ian On 30/11/2012 13:59, Simon Perreault simon.perrea...@viagenie.ca wrote: Le 2012-11-29 11:16, mohamed.boucad...@orange.com a écrit : As agreed in Atlanta, we prepared an I-D describing a proposed approach for the unified CPE. We hope this version is a good starting point to have fruitful discussion. Your comments, suggestions and contributions are more than welcome. Here are some: - First, I think this is very positive. I like what I'm reading. - Didn't we also consider public 4o6 as one mode? Any reason why it was left out? - Is public 4o6 the minor change to lw4o6 that section 4.1 hints at? - In section 3.2. Required Provisoning Information, I believe it would be possible and beneficial to specify only what each mode requires *in addition* to what the previous mode already provides. e.g. - DS-Lite requires the remote tunnel endpoint address. - In addition to that, lw4o6 requires the CPE's IPv4 address and port set. - In addition to that, MAP requires mesh routes. So each mode's provisioning parameters would be a superset of the previous one. (DS-Lite lw4o6 MAP) One we have this kind of hierarchical provisioning, we can define CPE behaviour in the same way. For example, MAP behaviour would be: 1. Do exactly what a lw4o6 CPE does. 2. In addition to 1, also send and receive packets directly to and from other CPEs according to the provisioned mesh routes. (I will refrain from commenting on section 4.4 until we have the higher-level design figured out.) Ian: I broadly agree with what you've said, but one use case that did cross my mind is if you only needed to provision mesh routes to a client with no need for a concentrator/default route. A closed machine-to-machine type service could be an example of this architecture. I'm not sure if it's a strong enough use case to build the provisioning model around, however. Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
Le 2012-11-30 14:09, mohamed.boucad...@orange.com a écrit : - Didn't we also consider public 4o6 as one mode? Any reason why it was left out? - Is public 4o6 the minor change to lw4o6 that section 4.1 hints at? Med: The rationale we adopted in this draft is as follows: * there are three major flavors: full stateful, full stateless, and binding mode * all these modes can support assigning a full or a shared IPv4 address As such Public4over6 is classified as part of binding mode (see Section 3) (2) Binding approach (e.g., Lightweight 4over6 (Lw4o6) [I-D.cui-softwire-b4-translated-ds-lite], [I-D.ietf-softwire-public-4over6] or MAP 1:1 [I-D.ietf-softwire-map] ): Requires a single per-subscriber state (or a few) to be maintained in the Service Provider's network. Ah, right, I missed that reference. Thanks. - In section 3.2. Required Provisoning Information, I believe it would be possible and beneficial to specify only what each mode requires *in addition* to what the previous mode already provides. e.g. - DS-Lite requires the remote tunnel endpoint address. - In addition to that, lw4o6 requires the CPE's IPv4 address and port set. - In addition to that, MAP requires mesh routes. So each mode's provisioning parameters would be a superset of the previous one. (DS-Lite lw4o6 MAP) Med: The current text of Section 3.2 says: +-+-+ |Mode | Provisioning Information| +-+-+ | DS-Lite | Remote IPv4-in-IPv6 Tunnel Endpoint | | Lw4o6 | Remote IPv4-in-IPv6 Tunnel Endpoint | | | IPv4 Address| | | Port Set| | MAP-E | Mapping Rules | | | MAP Domain Parameters | +-+-+ Table 4: Provisioning Information Note: MAP Mapping Rules are translated into the following configuration parameters: Set of Remote IPv4-in-IPv6 Tunnel Endpoints, IPv4 Address and Port Set. Can you please explicit the change you want to see appear in that text? Thanks. Something like: DS-Lite: - Remote IPv4-in-IPv6 Tunnel Endpoint Lw4o6: - DS-Lite set of provisioning information - IPv4 address - Port set MAP-E: - Lw4o6 set of provisioning information - Forwarding mapping rules My intuition is that with a unified CPE we don't need MAP to differentiate between basic mapping rule, forwarding mapping rule, and default mapping rule. - Basic mapping rule is just a forwarding mapping rule + IPv4 address + port set. - Default mapping rule is just the remote IPv4-in-IPv6 tunnel endpoint. So in MAP mode we can just provide forwarding mapping rules in addition to the stuff that L4o6 already requires. One we have this kind of hierarchical provisioning, we can define CPE behaviour in the same way. For example, MAP behaviour would be: 1. Do exactly what a lw4o6 CPE does. 2. In addition to 1, also send and receive packets directly to and from other CPEs according to the provisioned mesh routes. Med: Do you think this is different from the approach adopted in Section 4.3? Well just from reading I thought it was different. Maybe your intent was what I expected, just not formulated the way I expected it. One thing I expected to see is that if you take a unified CPE that only implements up to LW4o6 mode, and provision it with full MAP mode parameters, it will still work. It will ignore the forwarding mapping rules, and thus will not do mesh networking, but it will still work. Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
Le 2012-11-30 14:22, ian.far...@telekom.de a écrit : Ian: I broadly agree with what you've said, but one use case that did cross my mind is if you only needed to provision mesh routes to a client with no need for a concentrator/default route. A closed machine-to-machine type service could be an example of this architecture. Ah good point. I always forget about that use case. I'm not sure if it's a strong enough use case to build the provisioning model around, however. Not sure either. Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
On 30/11/2012 14:17, mohamed.boucad...@orange.com mohamed.boucad...@orange.com wrote: Re-, Please see inline/ Cheers, Med -Message d'origine- De : Wojciech Dec (wdec) [mailto:w...@cisco.com] Envoyé : vendredi 30 novembre 2012 13:21 À : BOUCADAIR Mohamed OLNC/OLN; draft-ietf-softwire-...@tools.ietf.org; draft-ietf-softwire-map-d...@tools.ietf.org; draft-ietf-softwire-public-4ov...@tools.ietf.org; draft-cui-softwire-b4-translated-ds-lite; Reinaldo Penno (repenno); softwires@ietf.org Objet : Re: Unified Softwire CPE: draft-bfmk-softwire-unified-cpe Hi Med., On 30/11/2012 12:10, mohamed.boucad...@orange.com mohamed.boucad...@orange.com wrote: -Message d'origine- De : Wojciech Dec (wdec) [mailto:w...@cisco.com] Envoyé : vendredi 30 novembre 2012 11:42 À : BOUCADAIR Mohamed OLNC/OLN; draft-ietf-softwire-...@tools.ietf.org; draft-ietf-softwire-map-d...@tools.ietf.org; draft-ietf-softwire-public-4ov...@tools.ietf.org; draft-cui-softwire-b4-translated-ds-lite; Reinaldo Penno (repenno); softwires@ietf.org Objet : Re: Unified Softwire CPE: draft-bfmk-softwire-unified-cpe Hi, While thanking the authors for their attempt, I need to provide some high level feedback first on key issues: The rationale section 1.1 states co-existance as the goal - this appears to imply some entirely different solutions for which co-existance is needed, and here are two points: A) I can agree that DS.-lite is an entirely different solution, but I firmly believe that it is entirely outside the agreed scope which was a unified solution CPE spec in the context of MAP and Lw4o6. Thus, I would recommend that ds.-lite be dropped from this draft as it bears no influence on unifying MAP and Lw4o6, nor does it bear anything on the already defined and shipped ds.-lite solution. Work on such themes of multiple solutions coexisting is what the v6ops CPE draft is covering and I would place ds.-lite coexistence there. Med: We included DS-Lite in the scope because of the following: * Several WG participants are concerned with optimizing the code and re-using existing modules. This is an implementation reason. Should we include in this draft anything that re-uses IPinIP tunneling, which is presumably the module in question? * Some DS-Lite components are shared with A+P solution: e.g., tunnel endpoint The tunnel endpoint is an address, and again, this hardly justfies ds.-lite inclusion Most notably the functionality of the regular DS.-lite AFTR is orthogonal to the working of the CPE. * A+P may be seen as an exit strategy of the CGN: optimisation migration path and required changes in the CPEs need to be taken into account. These topics are fine subject for some CGN-exit draft, rather then muddying up this one. Med: It is unfortunate to specify a unified CPE and exclude DS-Lite from it. All the solutions we are discussing have the same objectives: offer IPv4 service continuity over IPv6 network. Unlike A+P related solution, There are/were many unfortunate things in softwires, but keeping ds.-lite-isms out of this spec would certainly not be one of them. I sympathize with your POV that a way to co-exist is desired, and a CGN-exit draft needed, but that is simply *outside* the scope of this spec. The ds.-lite ship has sailed, and there is nothing common between this spec and ds.-lite other than RFC2473. Anything with RFC2473 heritage should be included otherwise. * DS-Lite code is already supported by some CPEs * NAT44 code is already supported by CPEs * A standard method to provision the remote IPv4-in-IPv6 tunnel endpoint The draft provides these items as a reminder. Having this big picture view will help in assessing which modules are worth to be re-used and which functions are missing. New solutions is almost a combination of existing modules + new configuration parameters. As I said earlier, all Section 3 can be removed to an appendix. I personally preferred to have in the core text for -00 so the WG is aware of: * solution flavors * subtleties between these solutions B) I disagree that co-existance between Lw4o6 and MAP is a goal; Med: MAP1:1 and lw4o6 are presented in the draft as soltuions for the binding mode. And the binding mode and duplicate descriptions should be removed IMO. a unified functional CPE spec for NAT44-less core relays accessed via IPv6 is. As such, describing modes as in solution modes is not conductive to that and a solution term neutral functional breakdown is essential and IMO possible (further explained below). This will only make the spec better and simpler for implementers. Med: This is what we tried to do in http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-00# section-4.3. In Section 3 the draft coin a new term/class of solution called Binding approach. Med: FYI, this is not a new term: please refer to http://tools.ietf.org/html/rfc6346#section-4.4. The point is that this is effectively configuration state, and calling it new terms is not changing
Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
Re-, -Message d'origine- De : Simon Perreault [mailto:simon.perrea...@viagenie.ca] Envoyé : vendredi 30 novembre 2012 14:24 À : BOUCADAIR Mohamed OLNC/OLN Cc : softwires@ietf.org Objet : Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe Le 2012-11-30 14:09, mohamed.boucad...@orange.com a écrit : - Didn't we also consider public 4o6 as one mode? Any reason why it was left out? - Is public 4o6 the minor change to lw4o6 that section 4.1 hints at? Med: The rationale we adopted in this draft is as follows: * there are three major flavors: full stateful, full stateless, and binding mode * all these modes can support assigning a full or a shared IPv4 address As such Public4over6 is classified as part of binding mode (see Section 3) (2) Binding approach (e.g., Lightweight 4over6 (Lw4o6) [I-D.cui-softwire-b4-translated-ds-lite], [I-D.ietf-softwire-public-4over6] or MAP 1:1 [I-D.ietf-softwire-map] ): Requires a single per-subscriber state (or a few) to be maintained in the Service Provider's network. Ah, right, I missed that reference. Thanks. - In section 3.2. Required Provisoning Information, I believe it would be possible and beneficial to specify only what each mode requires *in addition* to what the previous mode already provides. e.g. - DS-Lite requires the remote tunnel endpoint address. - In addition to that, lw4o6 requires the CPE's IPv4 address and port set. - In addition to that, MAP requires mesh routes. So each mode's provisioning parameters would be a superset of the previous one. (DS-Lite lw4o6 MAP) Med: The current text of Section 3.2 says: +-+-+ |Mode | Provisioning Information| +-+-+ | DS-Lite | Remote IPv4-in-IPv6 Tunnel Endpoint | | Lw4o6 | Remote IPv4-in-IPv6 Tunnel Endpoint | | | IPv4 Address| | | Port Set| | MAP-E | Mapping Rules | | | MAP Domain Parameters | +-+-+ Table 4: Provisioning Information Note: MAP Mapping Rules are translated into the following configuration parameters: Set of Remote IPv4-in-IPv6 Tunnel Endpoints, IPv4 Address and Port Set. Can you please explicit the change you want to see appear in that text? Thanks. Something like: DS-Lite: - Remote IPv4-in-IPv6 Tunnel Endpoint Lw4o6: - DS-Lite set of provisioning information - IPv4 address - Port set MAP-E: - Lw4o6 set of provisioning information - Forwarding mapping rules Med: Because of the dependency between the IPv4 address/IPv6 prefix, additional parameters are needed for MAP. This is why the table included two entries for MAP. My intuition is that with a unified CPE we don't need MAP to differentiate between basic mapping rule, forwarding mapping rule, and default mapping rule. - Basic mapping rule is just a forwarding mapping rule + IPv4 address + port set. - Default mapping rule is just the remote IPv4-in-IPv6 tunnel endpoint. So in MAP mode we can just provide forwarding mapping rules in addition to the stuff that L4o6 already requires. Med: you need also MAP parameters (offset, EA-...). One we have this kind of hierarchical provisioning, we can define CPE behaviour in the same way. For example, MAP behaviour would be: 1. Do exactly what a lw4o6 CPE does. 2. In addition to 1, also send and receive packets directly to and from other CPEs according to the provisioned mesh routes. Med: Do you think this is different from the approach adopted in Section 4.3? Well just from reading I thought it was different. Maybe your intent was what I expected, just not formulated the way I expected it. One thing I expected to see is that if you take a unified CPE that only implements up to LW4o6 mode, and provision it with full MAP mode parameters, it will still work. It will ignore the forwarding mapping rules, and thus will not do mesh networking, but it will still work. Med: Isn't this covered by the combination of these two points: o A network which supports one or several modes MUST return valid configuration data allowing requesting devices to unambiguously select a single mode to use for attachment. and (1) If a given mode is enabled (DS-Lite, Lw4o6 or MAP-E), the CPE MUST be configured with the required provisioning information listed in Table 4. If all of the required information is not available locally, the CPE MUST use available provisioning means (e.g., DHCP) to retrieve the missing configuration data. If one mode is enabled, the CPE won't ask
Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
Le 2012-11-30 15:18, mohamed.boucad...@orange.com a écrit : MAP-E: - Lw4o6 set of provisioning information - Forwarding mapping rules Med: Because of the dependency between the IPv4 address/IPv6 prefix, additional parameters are needed for MAP. This is why the table included two entries for MAP. I don't follow. A MAP default mapping rule is exactly like a forwarding mapping rule, with added semantics saying this chunk of IPv4 is yours. That can be split into a forwarding mapping rule + the usual LW4o6 parameters, can't you? My intuition is that with a unified CPE we don't need MAP to differentiate between basic mapping rule, forwarding mapping rule, and default mapping rule. - Basic mapping rule is just a forwarding mapping rule + IPv4 address + port set. - Default mapping rule is just the remote IPv4-in-IPv6 tunnel endpoint. So in MAP mode we can just provide forwarding mapping rules in addition to the stuff that L4o6 already requires. Med: you need also MAP parameters (offset, EA-...). That stuff is included in a forwarding mapping rule. One thing I expected to see is that if you take a unified CPE that only implements up to LW4o6 mode, and provision it with full MAP mode parameters, it will still work. It will ignore the forwarding mapping rules, and thus will not do mesh networking, but it will still work. Med: Isn't this covered by the combination of these two points: o A network which supports one or several modes MUST return valid configuration data allowing requesting devices to unambiguously select a single mode to use for attachment. and (1) If a given mode is enabled (DS-Lite, Lw4o6 or MAP-E), the CPE MUST be configured with the required provisioning information listed in Table 4. If all of the required information is not available locally, the CPE MUST use available provisioning means (e.g., DHCP) to retrieve the missing configuration data. If one mode is enabled, the CPE won't ask for more than what it needs. If its receives more, it will ignore them. I can add this to text if you think it is missing. I think it would be good, and I would even add a specific example of what happens if you plug a LW4o6 CPE in a MAP-enabled network. (What I wrote above.) Thanks, Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
Med, et al, Med: The rationale we adopted in this draft is as follows: * there are three major flavors: full stateful, full stateless, and binding mode * all these modes can support assigning a full or a shared IPv4 address now you got me thinking, are these really the right modes from a CPE perspective? let me try to explain, with my CPE implementor hat on, what modes would make sense? - NAT placement. do I need a NAT on the CPE or not? (no NAT no IPv4 address == DS-lite) - full IPv4 address assigned. I can assign the IPv4 address to the tunnel endpoint interface, and use that address for local applications, and as the outbound address of the NAT (mechanisms: MAP, Public 4over6) - IPv4 prefix assigned: I need to disable the CPE NAT, and use the assigned IPv4 prefix as my LAN side DHCPv4 pool (mechanism: MAP) - Shared IPv4 address. I must enable a local NAT, I cannot assign the IPv4 address on the WAN interface, but only use it for the outbound side of the NAT. then there might be a sub-modes for tunnel endpoint determination i.e. how to determine an IPv6 tunnel end point address given an IPv4 destination address and port. 1) algorithmic (MAP) 2) configured (Public 4over6, LW46, DS-lite) and a sub-mode for IPv4 address configuration: 1) As native IPv4 (Public4over6, LW46) 2) Embedded Address (MAP) 3) None DS-lite does this make sense? cheers, Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
thanks Med for the initialization of the work! i noticed that: 1. MAP is working in the context of prefix delegation and therefore the LAN side IPv6 addresses (prefix) is involved in the mapping between the IPv4 and IPv6, while lw4over6 applies the WAN IPv6 address directly. when a unified CPE is made, the logic of the address assignment to interfaces should also consider this difference in the behaviour. 2. is the deployment of difference modes able to be overlapped? current section 4.4 implies the answer is yes. i agree. but is it the best behaviour to select one mode at the device-wise according to a certain preferences? my question is: when the CPE receives multiple rules/parameter-sets from different sources of provisioning, can it store and use these pieces of information to adapt packets for corresponding mode of service, i.e., applying a proper mode on demand and session-specific? 3. related to 2, how can we keep the CPE/BR CPE/AFTR consistency? 4. fragmentation issue is common to all modes and it is also needed to be clarified/unified for the unified CPE. only my 2 cents, identifying the problems that i expect this draft to cover. - maoke 2012/11/29 Suresh Krishnan suresh.krish...@ericsson.com Thanks Med. This is a highly exploratory draft to be used as a strawman to determine if an unified CPE is even possible. Please comment on it so that we can determine if proceeding in this path is worthwhile. Also, if you are interested in being an editor of this draft and are not currently working on any of the current solution drafts please contact the chairs. Thanks Suresh - Original Message - From: mohamed.boucad...@orange.com mohamed.boucad...@orange.com To: draft-ietf-softwire-...@tools.ietf.org draft-ietf-softwire-...@tools.ietf.org, draft-ietf-softwire-map-d...@tools.ietf.org draft-ietf-softwire-map-d...@tools.ietf.org, draft-ietf-softwire-public-4ov...@tools.ietf.org draft-ietf-softwire-public-4ov...@tools.ietf.org, draft-cui-softwire-b4-translated-ds-lite draft-cui-softwire-b4-translated-ds-l...@tools.ietf.org, Reinaldo Penno (repenno) repe...@cisco.com, softwires@ietf.org softwires@ietf.org Sent: 11/29/2012 5:16 AM Subject: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe Dear all, As agreed in Atlanta, we prepared an I-D describing a proposed approach for the unified CPE. We hope this version is a good starting point to have fruitful discussion. Your comments, suggestions and contributions are more than welcome. Cheers, Med -Message d'origine- De : i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.org] De la part de internet-dra...@ietf.org Envoyé : jeudi 29 novembre 2012 10:57 À : i-d-annou...@ietf.org Objet : I-D Action: draft-bfmk-softwire-unified-cpe-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Unified Softwire CPE Author(s) : Mohamed Boucadair Ian Farrer Suresh Krishnan Filename: draft-bfmk-softwire-unified-cpe-00.txt Pages : 12 Date: 2012-11-29 Abstract: Transporting IPv4 packets over IPv6 is a common solution to the problem of IPv4 service continuity over IPv6-only provider networks. A number of differing functional approaches have been developed for this, each having their own specific characteristics. As these approaches share a similar functional architecture and use the same data plane mechanisms, this memo describes a specification whereby a single CPE can interwork with all of the standardized and proposed approaches to providing encapsulated IPv4 in IPv6 services. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-bfmk-softwire-unified-cpe There's also a htmlized version available at: http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ I-D-Announce mailing list i-d-annou...@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
