Hi all,
On 1/30/2012 7:31 PM, Ole Trøan wrote:
hi,
the MAP (Mapping of address and port) design team has now written and published
the following sets of drafts.
the base document (port mapping algorithm):
http://tools.ietf.org/html/draft-mdt-softwire-mapping-address-and-port-03
http://tools.ietf.org/rfcdiff?url2=draft-mdt-softwire-mapping-address-and-port-03.txt
the encapsulation document (MAP-E):
http://tools.ietf.org/html/draft-mdt-softwire-map-encapsulation-00
the translation document (MAP-T):
http://tools.ietf.org/html/draft-mdt-softwire-map-translation-00
the DHCP option (MAP-DHCP):
http://tools.ietf.org/html/draft-mdt-softwire-map-dhcp-option-02
there is a MAP deployment document coming soon.
the solution described in this set of documents, are written to satisfy the
following from the softwires charter:
4. Developments for stateless legacy IPv4 carried over IPv6
- develop a solution motivation document to be published as an RFC
- develop a protocol specification response to the solution
motivation document; this work item will not be taken through
in the design team's view, this set of documents are ready to be adopted as
working group documents.
No objection to the adoption of the base document, with some comments
(sorry if they've been discussed ever), please check below.
BTW, another question, I can' t remember the conclusion when the DT was
chartered, whether the -E and -T were the missions of the DT, or not?
----------------------------------------------------
1. Section 4., ...
The forwarding function uses the MRT to make forwarding decisions.
The table consist of the mapping rules. An entry in the table
consists of an IPv4 prefix and PSID. The normal best matching prefix
algorithm is used. With a maximum key length of 48 (32 + 16). E.g.
with a sharing ratio of 64 (6 bit PSID length) a host route for this
CE would be a /38 (32 + 6).
I'm confused here. The forwarding is based on routing tables (while IMHO
the Section 5.3 & 5.4 state it clearer),
the implementations may vary while the basic logic could be:
Each FMR should install one corresponding route in the IPv4 RIB, like,
Rule IPv4 prefix -> "connected", MAP Interface1
For outbound traffic from the private network, when the IPv4 RIB lookup is
performed, it should hit one element with a MAP interface, which can be
used as the pointer to the correct FMR in the MRT, to form the MAP IPv6
address of the destination.
2. Section 5.1.3., more text about what the "offset bits" is for, may
need to
be added, something like, "The length of offset bits determines the excluded
ports ..."
3. Section 5.2., ...
The offset of the EA bits field in the IPv6 address is equal to the
BMR Rule IPv6 prefix length. The length of the EA bits field (o) is
given by the BMR Rule EA-bits length. The sum of the Rule IPv6
Prefix length and the Rule EA-bits length MUST be less or equal than
the End-user IPv6 prefix length.
The prefix6-len + EA-bits len must be equal to the End-user IPv6 prefix
length, why there is a "less than"? Any reasonable use case about it?
4. Section 6., ...
In an encapsulation solution, an IPv4 address and port is mapped to
an IPv6 address. This is the address of the tunnel end point of the
receiving MAP CE. For traffic outside the MAP domain, the IPv6
tunnel end point address is the IPv6 address of the BR. The
interface-id used for all MAP nodes in the domain MUST be
deterministic.
How to do that, to make the interface-id deterministic? By the
interface-id formula specified?
...
The encoding of the full IPv4 address into the interface identifier,
both for the source and destination IPv6 addresses have been shown to
be useful for troubleshooting.
Does this statement apply to translation only, or to both?
----------------------------------------------------------
Cheers,
Jacni
comments?
for the MAP design team,
Ole
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
