Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd

[Maoke <[e-mail]>]

hi Remi,

2012/3/12 Rémi Després <[e-mail]>

>
> 2012-03-12 04:09, Maoke:
> ...
> > btw, BR also depends upon NAT44 to deal with the unknown protocol,
> right? if so, may i say your statement "BR will support them without
> needing an update" is a proposition actually not existing? because NAT44
> won't support them without any update. right?
>
> Not right. Only CEs that need to support a new protocol are concerned:
> - If a shared address server supports a new protocol, it can be reached
> via an unchanged BR.
> - If a client using a new protocol tries to reach a shared-address CE that
> doesn't support this protocol, the client will be returned an error message
> by the destination NAT44.
>

thanks a lot for the clarification! take an example:

 A --- NAT44/CE ---(IPv6 backbone of 4rd domain)--- BR ---(IPv4
Internet)--- B

now A and B are supposed to use a new protocol other than known
TCP/UDP/etc. my understanding:
B --> A
1. BR just passes the new protocol without any concern.
2. CE's NAT44 module would say "this is not supported and a 'destination
unreachable with port unknown' ICMP message is returned to B.
A --> B
1. CE's NAT44 module directly say "destination unreachable with port
unknown" ICMP message to A.

is the above what you mean? when NAT44 module DOESN'T support the new
protocol, things are working while we have no the problem about the
"change" at all for the time being.

then let's consider the case where the NAT44 module has been updated to
support the new protocol. i understand BR passing all protocols can be
survived if and only if the new protocol follows the TCP-layout for the
destination port and the TCP-checksum, right?

then you made a limitation (#1) to the NAT44 module of the CE: even if the
NAT44 has supported a new protocol not following TCP layout/checksum, this
support MUST be disabled in the 4rd-U environment; otherwise, BR may behave
wrong when making the mapped IPv6 addresses while the NAT44 would still try
to translate with the new protocol rather than dropping an error message
because it has known it. right?

further (#2), what if the packets don't pass through the NAT44 module at
all (in the case of non-shared IPv4 addresses)?

please clarify if the limitation of (#1) and (#2) are true or false. i
believe with requiring L4 modification, either MAP or RFC6145 has no such
two limitations: enforcing the checksum update at L4, their framework is
safe for either TCP-layout/checksum or alien-layout/checksum, either shared
or exclusive IPv4 addresses. i worry the CNP is making a situation of
"cutting feet to fit the shoes".

- maoke


>
> RD
>
>
>