> This is hardly a hack, it's a functional requirement of a CPE, specifying how > the CPE behaves with a case of NOT having an IPv4 address = no NAT44, in this > case. It's not about overflow. > > Besides that very obvious case to handle, I provided an explanation of the > value the described behaviour brings, which has also been demonstrated (per > Xing's mail). So far you have not substantiated what is the down-side of > having this functionality on a MAP CPE, other than considering it not useful. > Could you do that? > > Re: your substitution: No, an SP can hardly predict which CPEs in question > need to have DS-Lite capabilities (as in support ds-lite options, et al)
to take the overflow case, then you'd still need to provision this as two MAP domains. does it make much difference if you provision it as one MAP domain and one 6334 option? I'm in favour of having these mechanisms as ships in the night. given that we already have a way to provision DS-lite (6334), I wouldn't really be in favour of adding another one. I think CPE implementors have enough combinations already. ;-) cheers, Ole
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
