I think that the IPv6 destination address below should be
2001:db8::0:0:0a02:0304::
This is in Appendix A.
Example 3- FMR:
An IPv4 host behind a MAP-T CE (configured as per the previous
examples) corresponding with an IPv4 host 10.2.3.4 will have its
packets converted into IPv6
I also think that there should be a commitment from CPE vendors on this.
From: Softwires [mailto:softwires-boun...@ietf.org] On Behalf Of Ida Leung
Sent: Monday, September 29, 2014 7:41 AM
To: cy...@openwrt.org; softwires@ietf.org
Subject: Re: [Softwires] any CE vendors implementing MAP-E/T?
Hi there,
Are there any CE vendors that have implemented (or at least have firm plans to
implement) either MAP-E or MAP-T?
Thanks.
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
Just wanted to confirm one thing for MAP-E in regards to static port forwards.
Can it be assumed that excluded port-range (0-1023 and possibly more depending
on the offset) will never be used in MAP? The port forwards will be allocated
on the CPE in statefull NAT44 and the ports will be
But why is this a problem in CGN?
You initially allocate a port block of 500ports to the subscriber and then they
can dynamically extend this on as needed basis (allocate a new port block).
To me the value of this exercise is to determine what will this initial port
block size be, not at which
Can someone share some history and research backed data behind this statement
at the very bottom of section 4 in RFC 6145 (IP/ICMP Translation Algorithm).
The translator SHOULD make sure that the packets belonging to the
same flow leave the translator in the same order in which they
1) The MAP domain definition should be consolidated across the three
drafts (map-e, map-t and map-deployment).
For example the map-e draft defines under the terminology section the MAP
domain as:
MAP domain: One or more MAP CEs and BRs connected to the
MAP address. The BMR is an optional rule for a MAP CE.
Last sentence is not correct. It should state 'mandatory'.
From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf
Of Poscic, Kristian (Kristian)
Sent: Friday, March 15, 2013 9:57 AM
To: softwires@ietf.org
I was able to follow section 5.1 of this draft somewhat but then got completely
lost at step B3.
It would really help if you can also describe the reason why are you performing
each step - in other words put more context around it. Otherwise, it will be
very hard for the operators to follow
Sure. That will work.
-Original Message-
From: Ole Troan [mailto:o...@cisco.com]
Sent: Wednesday, March 13, 2013 6:52 AM
To: Poscic, Kristian (Kristian)
Cc: softwires@ietf.org
Subject: Re: [Softwires] softwire-map-04
Kris,
I think the following needs to be corrected in the softwire
Has any further work been done on:
draft-mdt-softwire-map-dhcp-option-03http://datatracker.ietf.org/doc/draft-mdt-softwire-map-dhcp-option/
draft-jiang-softwire-map-radius-02http://datatracker.ietf.org/doc/draft-jiang-softwire-map-radius/
There are many codes still missing in those two drafts.
was confused by the
‘Type TBD’ in section 4.1, page 5.
But I see now that the types are defined further below in the draft.
Thanks again.
Kris
From: Sheng Jiang [mailto:jiangsh...@huawei.com]
Sent: Wednesday, December 12, 2012 5:19 PM
To: Poscic, Kristian (Kristian); softwires@ietf.org
Cc: draft
be bigger trouble for the
operators than not .
why /56 instead of /52? :P = yes I agree it would be less wasteful.
Kris
From: Senthil Sivakumar (ssenthil) [mailto:ssent...@cisco.com]
Sent: Tuesday, December 11, 2012 11:34 AM
To: Maoke
Cc: Poscic, Kristian (Kristian); softwires@ietf.org
Subject: Re
Can someone clarify a few things for me:
1) Does MAP support this scenario (example):
- (BMR) Rule 1:
Rule IPv6 Prefix: 2001::/40
Rule IPv4 Prefix: 192.0.2.0/24
Rule EA-bits length:12
- (BMR) Rule 2:
Rule IPv6 Prefix:
Very helpful. Thanks!
From: Senthil Sivakumar (ssenthil) [mailto:ssent...@cisco.com]
Sent: Monday, December 10, 2012 5:03 PM
To: Poscic, Kristian (Kristian); softwires@ietf.org
Subject: Re: [Softwires] MAP-E/T overlaping ranges and domains
From: Poscic, Kristian (Kristian)
kristian.pos
Are any CE vendors already on board with map-e/t implementation?
In other words is there anything available today for early testing?
Thanks,
Kris
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
Need a quick clarification in regards to DMR in map-t:
- In map-E the BR addresses is part of DMR. So the packet will be sent
directly to the BR IPv6 address. Dest IPv4 as originated by the CE doesn't have
to be encoded in IPv6 dest addr since the BR can figure out the dest IPv4 from
Just to make sure I understand this.
Deterministic (statefull) NAT is deterministically translating inside IP to
outside IP + port range (take NAT44 case).
Deterministic stateLESS NAT is deterministically translating inside IP +
inside_src_port to outside IP + outside_src_port.
No states are
18 matches
Mail list logo
